Come fanno i manager a sapere se una persona è un programmatore buono o cattivo?

Nella maggior parte delle aziende che fanno i team di programmazione e le divisioni sono costituiti da programmatori che progettano e scrivono codice e gestori che ... beh, fanno le cose di gestione. Oltre a non scrivere codice, i manager di solito non guardano nemmeno il codice sviluppato dal team e potrebbero anche non avere un IDE corretto installato sulle loro macchine di lavoro.

Tuttavia, i manager devono giudicare se una persona lavora bene, se deve essere incaricata di qualcosa o se un determinato sviluppatore deve essere assegnato a un compito di maggiore importanza e responsabilità. E ultimo, ma non meno importante: i gestori di solito assegnano i bonus trimestrali!

Per fare quanto sopra in modo efficace, un manager dovrebbe sapere se una persona è un buon programmatore , ovviamente tra gli altri tratti. La domanda è: come lo fanno? Non guardano nemmeno il codice che le persone scrivono, non possono valutare direttamente la qualità dei componenti che i programmatori sviluppano ... ma le loro stime su chi è un buon programmatore e chi "non è buono" sono comunque corrette in la maggior parte dei casi!

Qual'è il segreto?

In genere un manager guarderà

• Il programmatore fa cose?
• Cosa ne pensano i loro colleghi? Il codice che scrivono?
• Il programmatore comunica chiaramente al gestore?
• Al programmatore piace imparare cose nuove? Mentorano bene gli altri?
• Hanno bisogno di molta attenzione da parte della direzione per fare le cose?
• Il programmatore sembra godersi il proprio lavoro?

È vero che di solito non vedono (o spesso capiscono) il codice dei dipendenti, ma quanto sopra per loro funge da proxy ragionevole per misurare quanto un dipendente si adatta al ruolo di programmazione imposto dal loro datore di lavoro. Se qualcuno non riesce a fare cose, ottiene voti bassi dai suoi colleghi, non riesce a comunicare bene, si sente frustrato con tecnologie diverse a cui sono abituati, ha sempre bisogno di supervisione ed è sempre infelice, è una buona indicazione che non sono " t maglia bene con questo lavoro. *

* Potrebbe essere, tuttavia, che in un contesto e un ambiente diversi sarebbero molto felici ed entusiasti. Forse è proprio quel tipo di programmatore a cui si sono opposti e potrebbero fare molto bene la programmazione in un contesto diverso. "Programmatore" può significare lavori molto diversi in luoghi diversi. Ma il manager si preoccupa principalmente del loro ruolo di "programmatore" e di come un dipendente si adatta.

Non sono d'accordo con l'affermazione che i manager non guardano il codice. Quando ho gestito i team, ho esaminato alcuni dei risultati di ogni ingegnere - e uno grande è il codice. Ma non l'unico - e-mail, documenti di progettazione, white paper - tutto ciò dipende da.

Ma questo non è sicuramente l'unico fattore. Se un ragazzo è seduto in un angolo e scrive codice brillante ma è una bestia con cui parlare, non risponderà alle domande, non condividerà lo stato e non scenderà a compromessi quando si presentano problemi di sviluppo - Non sono così sicuro che sia un risorsa per la squadra. Soprattutto rispetto a un ragazzo che scrive un codice moderatamente decente ma può fare tutto quanto sopra.

Ecco alcune cose che guardo quando sono in grado di dare ricompense, ma con l'enorme avvertimento che è assolutamente una reazione viscerale, perché nulla di tutto ciò può essere quantificato:

• Stato : è chiaro, preciso e tempestivo? Quando discusso, la persona è in cima allo stato o è un po 'sfocata sui problemi attuali? La persona ha il giusto giudizio per alzare una bandiera rossa quando qualcosa ha preso fuoco?
• Risoluzione dei problemi : sia la domanda che la risposta sono importanti. La persona sa quando chiedere aiuto o dove fa girare le ruote indefinitamente? Meglio ancora, quando altri hanno problemi, la persona aiuta a trovare la soluzione o diventa parte del problema? Anche avere il buon senso di arretrare quando il problema non è nella tua area di competenza vale alcuni punti. Inoltre, ci sono dei punti per uscire dal gruppo o dall'azienda e visitare siti come questo o altre risposte a Internet.
• L'attenzione al processo - di solito questo è abbastanza ovvio - anche in un'azienda non-ritentiva dell'analismo, se qualcuno sta facendo crollare il sistema, è visto nel caos che si lasciano alle spalle. Se altre persone stanno ripulendo le funzionalità di un'altra persona perché non aderiscono alla guida o all'architettura, allora abbiamo un problema. I punti bonus va a coloro che capire modi per rendere la consistenza e la qualità più facile .
• Percentuali di completamento vs. bug vs. complessità : esegui le operazioni, ma esegui correttamente. Tutti hanno alcuni bug, ma se il ragazzo fa le cose velocemente e ha problemi, abbiamo un problema. In genere trovo che questo non sia qualcosa che puoi valutare nel senso quotidiano: deve guardare indietro a una versione, una fase o un trimestre fiscale.

E input di altre persone. Spesso sono stato in una posizione in cui vari ingegneri erano responsabili di varie parti del progetto. A volte il team guida e talvolta solo i proprietari di una particolare porzione di output (come "the build guy"). Le persone AMANO parlare degli estremi: gli atti di eroismo o la frustrazione del problema dei bambini. Di solito nell'atto di dare seguito a questi problemi, scopro molto su ENTRAMBE le parti.

C'è anche un fattore che riguarda la gestione degli esseri umani . Nessun ingegnere è esattamente come un altro. Quindi non brillano tutti nella stessa luce. Uno scrive un brillante codice privo di bug, ma un altro aiuta a risolvere problemi trasversali che infrangono il codice di tutti. Uno è fantastico di persona, uno è meglio per iscritto. Uno è incoerente alle 9:00, uno è fuori di qui entro le 15:00. C'è un certo bisogno di fare un passo indietro, capire quale sia il più vantaggioso per la squadra e quale potrebbe essere un fattore di parzialità personale (come il desiderio di uccidere quel ragazzo cippatore alle 4:00 del mattino, solo perché non posso funzionare fino alle 11: 00 AM).

Questo varia notevolmente a seconda dell'esperienza tecnica del gestore.

• Per la maggior parte, probabilmente ti stanno giudicando su come comunichi . Come comunichi con il manager e come sei visto comunicare con i tuoi colleghi.
• Se sei fortunato ad avere uno sviluppatore principale che è più vicino al gestore, il gestore può chiedere informazioni allo sviluppatore principale.
• Tieni presente che la responsabilità principale del gestore è di fare le cose . Deve vedere produrre vari risultati e obiettivi per soddisfare il piano aziendale. Quindi, se in qualche modo riesci a sembrare come se avessi un'influenza diretta sul risultato , questo sarà di buon auspicio per te.

Generalmente no.

Ecco perché la programmazione è un "mercato dei limoni". http://en.wikipedia.org/wiki/The_Market_for_Lemons

Il codice viene rovinato, e generalmente non è per 2-3 anni prima che tu lo sappia. I programmatori rimangono in genere 18 mesi, quindi non si vedono mai i colpevoli del fallimento.

I gestori devono dire che, ad esempio, un rilascio richiede quattro mesi e cento iterazioni. Forse stai modificando molti file di distribuzione manualmente e leggendo manualmente i file di registro per errori mescolati con lo stato? Non sanno che potrebbe essere fatto meglio.

Quindi sii onesto e professionale e cerca di migliorare. Con l'esperienza un manager inizierà a vedere modelli di comportamento buono e cattivo.

Come fanno i manager a sapere se una persona è un programmatore buono o cattivo?

Inizierò con una generalizzazione generalizzata: la maggior parte dei manager non può distinguere un programmatore "buono" da un programmatore "cattivo".

A parte questo, ciò che la maggior parte dei manager (per cui ho incontrato o lavorato) considera "buono" in un programmatore non è la stessa serie di competenze che un altro programmatore considererebbe "buono".

Come lo fanno?

Un manager orientato ai risultati cercherà cose come "intelligenti" e "farà le cose". A loro non importa se ti presenti per lavorare in pantaloni della tuta fintanto che fai le cose in tempo e in budget.

Un manager orientato al processo è più interessato a "come vengono fatte le cose". Ciò significa mettersi al lavoro in tempo, indossare l'abbigliamento giusto e avere la copertina giusta nel rapporto TPS.

la persona lavora bene, se deve essere incaricata di qualcosa

Essere "in carica" ​​richiede competenze diverse rispetto alla scrittura di codice. Se una persona ha le competenze necessarie per guidare una squadra, quella persona dovrebbe essere sfruttata per farlo. Se promuovi le persone in base agli elementi chiave del lavoro che svolgono attualmente, alla fine raggiungono un livello in cui sono ora incompetenti. Questo si chiama The Peter Principle .

Ovviamente aiuta sempre avere un manager esperto di programmazione in grado di leggere effettivamente il codice e, ancora più importante, approfondire il sistema di tracciamento dei bug e capire cosa sta succedendo, sapere che non tutti i bug sono creati uguali e che la consegna tempestiva di codici errati non conta per molto.

Ma questo è un caso ideale. Per un manager di ottenere la misura di un programmatore da una prospettiva non tecnica, ho un paio di suggerimenti.

• Evidenziano prontamente / regolarmente / coerentemente dove ci sono problemi nel portare a termine le cose per soddisfare i requisiti attualmente specificati ... e sono completamente fastidiosi a causa di ciò (questo è lo sviluppo del software, dopo tutto, se non è abbastanza complesso da avere questi problemi, non è un vero progetto di sviluppo).
• Se non sono sicuri di qualcosa, lo dicono immediatamente: solo un programmatore sicuro delle proprie capacità lo farebbe effettivamente (e sanno che se non ti piace, possono facilmente ottenere un altro lavoro). Al contrario qualcuno che sa di essere seriamente fuori dalla propria profondità tende a nascondersi e cercare riparo.
• Che cosa dicono / implicano gli altri programmatori del team sugli altri programmatori? Se sei un manager mezzo decente, sei in trincea con il tuo team di programmazione, specialmente durante i test di integrazione / tempo di correzione dei bug. Quindi, se non ricevi questo tipo di feedback, qualcun altro dovrebbe fare il tuo lavoro.
• E il mio preferito: quello che chiamo programmatore "tomcat". Se dopo un po 'ti accorgi costantemente di vari programmatori che si muovono sempre attorno allo stesso desk del programmatore (supponendo che stiano facendo un lavoro e discutendo di qualche problema problematico, e non il cercatore residente di webstuff simpatici e divertenti) ... allora c'è un motivo per cui altri programmatori stanno gravitando sulla scrivania di quella persona. Se non sono già un caposquadra, probabilmente dovrebbero essere fatti al più presto.

Se uno o tutti questi si applicano, è probabile che tu abbia un buon programmatore nelle tue mani. Si noti che da un buon programmatore non solo valuto la loro capacità di codifica, ma altre cose utili come essere in grado di comunicare con altri esseri umani ;-)

Il gestore potrebbe non sapere quando il codice che scrivi è brillante o se potrebbe essere migliorato da un fattore enorme, ma quello che sa è: hai rispettato la scadenza con il codice che ha funzionato? Sei una persona di cui si può fidare per risolvere i problemi che altre persone creano? Il cliente o l'utente ha notato un problema che è stato inoltrato al suo manager? Si è verificato un grave disastro sul tuo orologio (eliminato la tabella degli utenti, dimenticato di impostare i backup, inviato un'e-mail ai clienti con i dati di proprietà di un altro cliente che non avrebbero dovuto vedere, ecc. Qualcuno si è complimentato con il tuo lavoro (specialmente per iscritto) )? Le persone dicono cose buone o cattive alle tue spalle?

1. Nella maggior parte dei casi in cui il tuo codice non viene valutato dal tuo manager, viene valutato dai tuoi colleghi (formalmente o informalmente quando provano a lavorare con il tuo codice). Il tuo capo utilizzerà le opinioni dei tuoi colleghi (di nuovo, sia formali che informali) in una certa misura.
2. La tua affidabilità generale e la velocità con cui avanzi e finisci le attività sono spesso un fattore molto importante, separato dalla tua capacità di codifica.
3. Comunicazione. Se stai facendo molto e lo fai bene, il tuo manager deve saperlo! (Evitare di vantarsi, ovviamente). Impara a "gestire il tuo manager" e non semplicemente essere passivo. Aiuta il tuo capo a sapere come lavori.

I gestori sono programmatori stessi e quindi, con una semplice osservazione, possono capire se il programmatore è buono o no.

Se i tuoi manager non sono programmatori (e sei nel business del software), sei fregato.

Come manager, ecco alcune delle cose che ho visto quando ho valutato i miei programmatori:

• Feedback tra pari. Ho chiesto ai programmatori del mio team e ai programmatori di altri team di inviarmi un feedback sulla mia gente.

• Rispetto dei pari . Quando i miei programmatori incontrano un problema che non possono risolvere, dicono "andiamo a chiedere un consiglio."

• Fa le cose . Dico "Voglio X" e il giorno dopo, X è fatto.

• Diventa intelligente . Dico "Voglio X" e il giorno dopo, non solo X è fatto, ma tutte le cose simili a X vengono risolte e non richiedono ulteriore attenzione.

• Mi aggiusta . Dico "Voglio X" e il programmatore dice "X non è giusto, dovremmo fare Y, ed ecco perché".

Non ci sono molti bravi manager là fuori (vedi domanda correlata: come fanno i progammatori a sapere se una persona è un manager buono o cattivo?). Gestire bene le persone è difficile e richiede molto tempo e duro lavoro. Non appena gestivo 5 persone, non avevo quasi tempo per programmare. Quando gestivo più di 8 persone, non potevo più gestirle come meritavano.

Penso che la premessa della tua domanda sia in qualche modo errata in quanto afferma che i gestori non guardano effettivamente al codice. Ho lavorato in molte situazioni in cui i miei manager erano colleghi ingegneri e hanno partecipato attivamente alle revisioni del codice.

Tuttavia, ci sono sicuramente una pluralità di situazioni in cui una persona non tecnica è responsabile di ingegneri del software e non sono in grado di fare affidamento sulla propria conoscenza ed esperienza.

In questi casi, i responsabili responsabili chiameranno i colleghi dell'ingegnere per un consiglio. Chiederanno alle persone non tecniche dell'organizzazione con le quali l'ingegnere interagisce per vedere se possiede abilità di persone buone che sono compatibili con una maggiore responsabilità.

Quelli irresponsabili andranno semplicemente con le loro reazioni "viscerali" e usano una sorta di "metrica" ​​generalmente insopportabile.

È uno schifo, ma puoi sempre smettere e sperare in qualcosa di meglio altrove.

Dove lavoro, quando arrivano le valutazioni dei dipendenti, i manager inviano un interrogatore anonimo e informale a coloro che interagiscono regolarmente con il dipendente; sia compagni sviluppatori che clienti. Ciò offre agli altri sviluppatori l'opportunità di fornire input sulle prestazioni come programmatore che i manager potrebbero altrimenti trascurare.

Il manager deve esaminare le misure misurabili. Quali aspetti del lavoro sono misurabili in termini di lavoro svolto, qualità del lavoro. Potrebbero non sapere se stai facendo un lavoro di qualità, a meno che tu non generi molti errori o non consenta all'utente finale di fare ciò che dovrebbe fare.

Il tuo lavoro costa al manager denaro in spese, quindi devi essere finanziariamente redditizio per continuare a lavorare.

Non sto dicendo che questo è il modo migliore per farlo, ma potrebbero basarlo sulla soddisfazione del cliente. Se a loro piace l'applicazione, accetta la quantità di bug e ritiene di aggiungere nuove funzionalità in modo tempestivo, i tuoi sviluppatori potrebbero davvero essere così male?

Certo che potevano. Sono in grado di forzare la forza attraverso la programmazione perché hai 10 persone che svolgono il lavoro di due. Oppure i clienti sono soddisfatti perché vendi la tua app in modo economico.

Un altro problema con questo approccio è che devi attendere che un'applicazione sia quasi completata prima che il responsabile non tecnico possa ottenere il feedback dei clienti. Costruisci un'app solo per un anno per rilasciarla e a nessuno piace.

La vita sarebbe più semplice se potessi contare sul dire alle persone di "Fallo funzionare". Quando capisci e fai aderire le persone al processo giusto, elimini molti problemi. Puoi avere scadenze impegnative che sono realistiche. Ogni sciocco può presentare richieste non realistiche e correre il rischio di perdere persone di talento.

Penso che la maggior parte di noi di un team tecnico sappia chi fa rock e chi fa schifo. A meno che tu non abbia un enorme turnover, la crema sale in alto e il peso morto diminuisce. Gli sviluppatori scadenti hanno sempre qualche tipo di problema: dimenticano di testare il loro codice prima di controllarlo, quindi le build si rompono, hanno sempre una scusa quando non riescono a fare qualcosa, e così via.

Penso che non sappiano se qualcuno è un buon programmatore , perché non hanno le competenze per farlo. Controllano se qualcuno è un buon sviluppatore . La programmazione è un'attività di sviluppo, ma lo sviluppo ha molti altri. Quindi controllano se sei puntuale, se le tue stime sono buone, se ci sono molti difetti su cose che hai fatto nel tuo sistema di tracciamento dei bug, le tue competenze trasversali, impegno, comunicazione, ecc.

Ciò che alcuni Guru a volte dimenticano e si arrabbiano è che il nostro lavoro non è solo programmazione, ma abbiamo anche molte altre cose da fare che sono molto importanti. Mentre il tuo manager non darà un'occhiata a come appare il tuo codice (perché è completamente irrilevante per lui), controllerà se sei un giocatore di squadra, responsabile, rispettoso e fai un lavoro di alta qualità in generale .

A volte penso che il codice sia sopravvalutato.

Penso che ci siano pochissime persone (per non parlare dei manager) che non hanno una buona comprensione generale dell'ordine di beccata per gli sviluppatori. Tutti pensano di essere uno sviluppatore di prim'ordine, le uniche persone che non sanno chi sono i cattivi sviluppatori, sono quegli stessi cattivi sviluppatori. Ad ogni modo, se dovessi andare in giro e chiedere a qualcuno di classificare gli sviluppatori con cui lavorano sono sicuro che sarebbe un compito facile per la maggior parte delle persone. Quindi non c'è magia nel determinare chi si esibisce molto bene e chi si comporta in modo medio o cattivo, ecc ... L'unico gotcha in cui sviluppatori e manager non saranno d'accordo con quei tipi di venditori, quelli rumorosi che sembrano sapere di cosa stanno parlando ma davvero no. La maggior parte dei gestori sono confusi da loro, ma gli sviluppatori no.

Successivamente, sono i pregiudizi del tuo manager a determinare la tua classifica. Per alcuni, la codifica è un'attività entry level, quindi sebbene tu possa essere eccellente nel codificare, non otterrai la promozione che stai cercando. Mentre altri considerano il design o gli aspetti architettonici più importanti. E altri ritengono che la definizione e la raccolta dei requisiti (ad es. Analisi di business) siano i più importanti. Se vuoi sapere cosa è importante per il tuo manager e non hai ottenuto la classifica delle migliori prestazioni, chiedi loro cosa devo fare per ottenere una classifica delle migliori prestazioni? Imparerai anche ciò che è importante per loro in quella risposta e poi spetta a te assicurarti di eccellere in quelle aree di importanza.