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

Tipicamente un gestore guarderà

• Il programmatore ha finito?
• Cosa ne pensano i loro colleghi di loro? Il codice che scrivono?
• Il programmatore comunica chiaramente al manager?
• Il programmatore si diverte a imparare cose nuove? Mentono bene gli altri?
• Hanno bisogno di molta attenzione da parte del management per ottenere risultati?
• Il programmatore sembra godere del suo lavoro?

È vero che di solito non vedono (o spesso capiscono) il codice dei dipendenti, ma quanto sopra per loro serve come proxy ragionevole per misurare quanto bene un dipendente si adatta al ruolo di programmazione imposto loro dal proprio datore di lavoro. Se qualcuno non sta facendo qualcosa, ottiene voti bassi dai colleghi, non riesce a comunicare bene, si sente frustrato con una tecnologia diversa da quella a cui è abituato, ha sempre bisogno di supervisione, ed è sempre infelice, è una buona indicazione che non sono " t fare i migliori affari con questo lavoro. *

* Potrebbe essere, tuttavia, che in un contesto e in un ambiente diversi sarebbero molto felici ed entusiasti. Forse è solo un 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 soprattutto del loro ruolo di "programmatore" e di come si adatta un dipendente.

Non sono d'accordo con l'affermazione che i manager non guardano il codice. Quando ho gestito team, ho esaminato parte dell'output di ogni ingegnere, e uno grande è il codice. Ma non l'unico - e-mail, documenti di design, white paper - tutti fattori.

Ma non è sicuramente l'unico fattore. Se un ragazzo è seduto in un angolo e sta scrivendo un codice brillante ma è una bestia con cui parlare, non risponderà alle domande, non condividerà lo stato e non scenderà a compromessi quando si presenteranno problemi rilevanti - I Non sono sicuro che sia un vantaggio per la squadra. Soprattutto se paragonato a un ragazzo che scrive codice moderatamente decente, ma può fare tutto quanto sopra.

Ecco alcune cose che guardo quando sono in grado di dare dei premi, ma con l'enorme avvertenza che è assolutamente una reazione istintiva, perché nessuna di queste può essere quantificata:

• Stato : è chiaro, preciso e & tempestivo? Quando viene discusso, la persona in cima allo stato o un po 'sfocata sui problemi attuali? La persona ha il diritto di sollevare una bandiera rossa quando qualcosa ha preso fuoco?
• Risoluzione dei problemi - sia chiedere che rispondere è importante. La persona sa quando chiedere aiuto o dove gira indefinitamente le ruote? Meglio ancora, quando gli altri hanno problemi, la persona aiuta a trovare la soluzione o diventa parte del problema? Anche avere il buon senso di fare marcia indietro quando il problema non è nella tua area di competenza vale alcuni punti. Inoltre, ci sono dei punti per andare fuori dal gruppo o dall'azienda e andare a siti come questo o altre risposte a Internet.
• Attenzione al processo - di solito questo è abbastanza ovvio - anche in un'azienda non ritentiva dal punto di vista anale, se qualcuno è in controtendenza, si vede nel caos che lasciano dietro di sé. Se altre persone stanno ripulendo le caratteristiche di un'altra persona perché non aderiscono alla guida o all'architettura, allora abbiamo un problema. I punti bonus vanno a coloro che escogitano modi per rendere la coerenza e la qualità più semplici .
• Tassi di completamento contro bug e complessità : ottieni risultati, ma fallo correttamente. Ognuno ha qualche bug, ma se il ragazzo ha fatto cose veloci e bug abbiamo un problema. In generale, trovo che non sia qualcosa che puoi valutare nel senso quotidiano - deve guardare indietro a una release, a una fase oa un trimestre fiscale.

E l'input di altre persone. Spesso sono stato in una posizione in cui diversi ingegneri erano responsabili di varie parti del progetto. A volte il team guida, e talvolta solo i proprietari di un particolare pezzetto di output (come "il tipo di build"). La gente AMA parlare degli estremi: gli atti di eroismo o la frustrazione dei bambini problematici. Di solito nell'atto di seguire le mani su quei problemi, scopro molto su ENTRAMBI i party.

C'è anche un fattore in ciò che riguarda Gestione degli esseri umani . Nessun ingegnere è esattamente uguale a nessun altro. Quindi non tutti brillano nella stessa luce. Uno scrive un codice brillante senza bug, ma un altro aiuta a risolvere i problemi trasversali che infrangono il codice di tutti. Uno è grande di persona, uno è migliore 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 cosa è più vantaggioso per la squadra e quale potrebbe essere un fattore di pregiudizio personale (come il desiderio di uccidere quel ragazzo alle quattro del mattino, solo perché non posso funzionare fino alle 11: 00 AM).

Varia di molto in base alle competenze tecniche del manager.

• Per la maggior parte, probabilmente ti stanno giudicando su come comunicare . In che modo comunichi con il gestore e in che modo ti vedi comunicare con i tuoi colleghi.
• Se sei fortunato ad avere uno sviluppatore principale che è più vicino al gestore, il gestore può chiedere input allo sviluppatore principale.
• Tieni presente che la responsabilità principale del manager è quella di ottenere risultati . Ha bisogno di vedere la produzione di vari risultati e obiettivi per soddisfare il piano aziendale. Quindi, se sei in qualche modo in grado di guardare come se avessi una influenza diretta sul risultato , questo sarà di buon auspicio per te.

Generalmente no.

Ecco perché la programmazione è un "mercato per i limoni". link

Il codice viene incasinato, e generalmente non lo è per 2-3 anni prima che tu lo sappia. I programmatori di solito rimangono 18 mesi, quindi non si vedono mai i colpevoli al fallimento.

I manager devono tener fede al fatto che, ad esempio, un rilascio richiede quattro mesi e cento iterazioni. Forse stai modificando a mano molti file di distribuzione e leggendo a mano i file di registro per errori combinati con lo stato? Non sanno che potrebbe essere fatto meglio.

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

How do managers know if a person is a good or a bad programmer?

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

Con ciò, la maggior parte dei manager (che ho incontrato o lavorato per) considerano "buono" in un programmatore non lo stesso insieme di abilità che un altro programmatore considererebbe "buono".

how do they do it?

Un manager orientato ai risultati sta cercando cose come "intelligenti" e "fa le cose". A loro non importa se ti presenti al lavoro con i pantaloni della tuta, a patto che tu faccia i compiti in tempo e con il budget.

Un manager orientato al processo è più interessato a "come si fanno le cose". Questo significa arrivare al lavoro in orario, indossare gli indumenti giusti e hai la copertina giusta sul rapporto TPS.

person works well, if he or she should be put in charge of something

Essere "responsabili" richiede competenze diverse rispetto alla scrittura del codice. Se una persona ha le competenze necessarie per guidare una squadra, allora quella persona dovrebbe essere TAPpata per farlo. Se promuovi persone basate sugli elementi chiave del lavoro che stanno svolgendo, alla fine raggiungono un livello in cui sono ora incompetenti. Questo è chiamato Il principio di Peter .

Ovviamente aiuta sempre ad avere un manager esperto di programmazione che può effettivamente leggere 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 solo consegnare codice non valido in tempo contiamo molto.

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

• Evidenziano tempestivamente / regolarmente / coerentemente dove ci sono problemi nell'ottenere le cose fatte 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 davvero (e sanno che se non ti piace, possono facilmente ottenere un altro lavoro). Al contrario, qualcuno che sa di essere seriamente fuori dalla loro profondità tende a nascondersi e cercare la copertura.
• Che cosa dicono / implicano altri programmatori del team riguardo agli 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 ottieni questo tipo di feedback, qualcun altro dovrebbe svolgere il tuo lavoro.
• E il mio preferito: quello che chiamo il programmatore 'tomcat'. Se dopo un po 'noterai costantemente vari programmatori che si aggirano sempre attorno alla stessa scrivania del programmatore (supponendo che stiano facendo del lavoro e discutendo di un problema fastidioso, e non il cercatore residente di fantastici e divertenti webstuff) ... allora c'è un altro motivo i programmatori stanno gravitando sulla scrivania di quella persona. Se non sono già un capo squadra, probabilmente dovrebbero essere fatti al più presto.

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

Il manager 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 funzionante? Sei una persona di cui fidarsi per risolvere i problemi che altri peopel creano? Il cliente o l'utente ha notato un problema che è stato inoltrato al suo manager? C'è stato un grave disastro sul tuo orologio (cancellata la tabella degli utenti, dimenticato di impostare i backup, inviato una email ai clienti con dati proprietari di un altro cliente che non avrebbero dovuto vedere, ecc. Qualcuno ha complimentato il tuo lavoro con lui (specialmente nella scrittura)? Le persone dicono cose buone o cattive alle spalle?

1. Nella maggior parte dei casi in cui il tuo responsabile non valuta il tuo codice, viene valutato dai tuoi pari (sia formalmente che informalmente quando cercano di lavorare con il tuo codice). Il tuo capo userà le opinioni dei tuoi pari (anche in questo caso formali o informali) in una certa misura.
2. La tua affidabilità generale e la velocità con cui procedi e finisci le attività è 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! (Evita di vantarti, ovviamente). Impara a "gestire il tuo manager" e non essere semplicemente passivo. Aiuta il tuo capo a sapere come lavori.

I gestori sono gli stessi programmatori e quindi, per semplice osservazione, possono capire se il codificatore è buono o meno.

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

In qualità di manager, ecco alcune delle cose che ho esaminato durante la valutazione dei miei programmatori:

• Feedback peer. Ho chiesto ai programmatori della mia squadra e ai programmatori di altri team di inviarmi feedback sulla mia gente.

• Rispetto dei pari . Quando i miei programmatori incontrano un problema che non riescono a risolvere, dicono "andiamo a chiedere il così-così-così per un consiglio".

• Ottiene cose fatte . Dico "Voglio X" e il giorno dopo, X è fatto.

• Ottiene cose intelligenti . Dico "Voglio X" e il giorno dopo, non solo X è terminato, ma tutte le cose simili a X sono risolte e non richiedono ulteriore attenzione.

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

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

Penso che la premessa della tua domanda sia un po 'errata in quanto afferma che i manager non guardano effettivamente il codice. Ho lavorato in molte situazioni in cui i miei manager erano un collega ingegnere e partecipavo attivamente alle revisioni del codice.

Tuttavia, ci sono sicuramente una pluralità di situazioni in cui una persona non tecnica è responsabile degli ingegneri del software e non sono in grado di fare affidamento sulle proprie conoscenze ed esperienze.

In questi casi, i responsabili responsabili chiameranno i colleghi dell'ingegnere per un consiglio. Chiederanno alle persone non tecniche dell'organizzazione con cui l'ingegnere interagisce per vedere se ha delle brave persone che sono compatibili con una maggiore responsabilità.

Gli irresponsabili andranno solo con le loro reazioni "intestinali" e usano una sorta di "metrica" generalmente insopportabile.

È una sparatoria, ma puoi sempre smettere e sperare in qualcosa di meglio altrove.

Dove lavoro, quando le valutazioni dei dipendenti arrivano, i manager inviano un questionario informale e anonimo a coloro che interagiscono regolarmente con il dipendente; sia i colleghi sviluppatori sia i clienti. Ciò offre ai colleghi sviluppatori l'opportunità di dare un input sulla performance come un programmatore che i manager potrebbero altrimenti trascurare.

Il manager deve esaminare i valori 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 permetta all'utente finale di fare ciò che dovrebbe fare.

Il tuo lavoro costa al gestore denaro in spese, quindi devi essere finanziariamente redditizio per continuare l'occupazione.

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

Certo che potrebbero. Sono in grado di potenziare la forza attraverso la codifica perché hai 10 persone che fanno il lavoro di due. Oppure i clienti sono soddisfatti perché vendi la tua app in modo così economico.

Un altro problema con questo approccio, è che devi attendere fino a quando un'applicazione non è quasi completata prima che il manager non tecnico possa ottenere un feedback dal cliente. Costruisci un'app per un anno solo per pubblicarla e non piace a nessuno.

La vita sarebbe più semplice se potessi fare affidamento sul dire alla gente di "Falla funzionare". Quando comprendi e fai aderire le persone al processo giusto, elimini molti problemi. Puoi avere scadenze impegnative che sono realistiche. Qualsiasi stupido può presentare richieste non realistiche e correre il rischio di perdere persone di talento.

Penso che la maggior parte di noi in un team tecnico sappia chi fa schifo e chi fa schifo. A meno che tu non abbia un enorme fatturato la crema sale verso l'alto e il peso morto affonda. Gli sviluppatori scadenti sono sempre in una sorta di guai: dimenticano di testare il loro codice prima che lo facciano, quindi hanno sempre una scusa quando non riescono a fare qualcosa, e così via.

Penso che non sappiano se qualcuno è un buon programmatore , beucase non hanno le capacità per farlo. Controllano se qualcuno è un buon sviluppatore . La programmazione è un'attività di sviluppo, ma lo sviluppo ne ha molti altri. Quindi controllano se sei in orario, se le tue stime sono buone, se ci sono molti difetti sulle cose che hai fatto nel tuo sistema di tracciamento dei bug, le tue soft skills, impegno, comunicazione, ecc.

Ciò di cui alcuni guru a volte dimenticano e si arrabbiano è che il nostro lavoro non è solo programmazione, abbiamo molte altre cose da fare che sono anche molto importanti. Mentre il tuo manager non dà un'occhiata a come è 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 conoscenza generale del gerarchia degli sviluppatori. Tutti pensano di essere uno sviluppatore di prim'ordine, le uniche persone che non sanno chi siano i cattivi sviluppatori sono gli 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'è alcuna magia nel determinare chi sta performando molto bene e chi sta performando nella media o nella cattiva, ecc. L'unico modo in cui sviluppatori e manager non sono d'accordo sono con quei tipi di venditori, quelli che suonano come sanno di cosa stanno parlando circa ma davvero no. La maggior parte dei manager li ha ingannati, ma gli sviluppatori no. Di solito, il venditore richiede un errore epico prima che il gestore prenda piede.

Dopo questo, sono i pregiudizi del tuo manager che determinano il tuo posizionamento. Per alcuni, la codifica è un'attività di livello base, quindi anche se potresti essere bravo a codificare, non otterrai quella 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 esempio l'analisi aziendale) sia la più importante. Se vuoi sapere che cosa è importante per il tuo manager e non hai ottenuto un ranking top performer, chiedi loro cosa devo fare per ottenere un ranking migliore? Imparerai ciò che è importante anche loro in quella risposta e poi spetta a te assicurarti di eccellere in quelle aree importanti.