E 'possibile misurare se qualcuno è un programmatore "buono"? [duplicare]

La matrice delle competenze dei programmatori è una risorsa notevole tra i programmatori. Elenca i criteri di 4 livelli di competenza per 32 tipi di competenze di programmatore (abilità) che sono a loro volta raggruppate in 5 sezioni:

Computer Science

• data structures
• algorithms
• systems programming

Software Engineering

• source code version control
• build automation
• automated testing

Programming

• problem decomposition
• systems decomposition
• communication
• code organization within a file
• code organization across files
• source tree organization
• code readability
• defensive coding
• error handling
• IDE
• API
• frameworks
• requirements
• scripting
• database

Experience

• languages with professional experience
• platforms with professional experience
• years of professional experience
• domain knowledge

Knowledge

• tool knowledge
• languages exposed to
• codebase knowledge
• knowledge of upcoming technologies
• platform internals
• books
• blogs

Efficienza finale

Davy Brion dice:

The only way to objectively measure this is to define a new metric which holds into account the extra effort that will be introduced later on.I'd call this metric Eventual Efficiency.

e

Unfortunately, we'll probably never get to the point where we can actually measure the Eventual Efficiency of developers.

Da questo articolo

Tendo ad essere d'accordo. Ma dal momento che abbiamo bisogno di qualcosa di "Peer review" e una matrice di competenze dovrà fare. Per la matrice non andrei con uno generale ma ne metteremo uno che conta per la mia organizzazione. E includerebbe solo cose che puoi misurare o valutare. Suggerimenti come:

• recensioni peer
• conoscenza di base (fai domande sulla conoscenza della programmazione che è rilevante per la tua organizzazione)
• risoluzione dei problemi
• esperienze sofar
• capacità di presentazione (non è necessario essere una vera presentazione, ma almeno il programmatore deve essere in grado di motivare le sue scelte)
• conoscenza del dominio
• conoscenze extra oltre alla competenza di base (gestione del progetto, infrastruttura, sicurezza, ecc.)
• dimensioni della scarpa ovviamente (più piccole sono e meglio è)
• se è per le valutazioni l'accuratezza della pianificazione personale del programmatore (quando lui / lei dice che sarà fatta in 3 giorni, è generalmente fatta in 3 giorni.
• se è per le valutazioni, il programmatore aiuta gli altri
• se è per le valutazioni, anche il programmatore è interessato a risolvere problemi al di fuori delle sue responsabilità

Cose a cui davvero non mi importa.

• linee di codice ovviamente
• incontro di deadline esterne
• la possibilità di pronunciare molte parole d'ordine e inserirle in una frase

Nelle squadre con cui ho lavorato, ho notato i seguenti ruoli:

• Lo sviluppatore che corregge i bug che nessun altro può risolvere
• Lo sviluppatore che lavora su una macchina virtuale
• Il direttore della fotografia
• Lo sviluppatore che riduce 1000 righe di codice a 100 che sono molto più facili da capire
• La prima donna
• Lo sviluppatore in grado di rompere un problema complesso enorme in piccoli pezzi gestibili
• Lo sviluppatore write-once - per qualche ragione, lo fanno bene la prima volta con pochissimi bug
• Donna
• L'architetto che può visualizzare i dati trasferiti da sistema a sistema a sistema
• El Gaucho
• Il responsabile del processo che migliora costantemente il modo in cui costruiamo, testiamo e implementiamo
• Il sandbagger

Non ci sono regole scritte su chi si qualifica per ciascun ruolo, eppure tutti nel team sanno chi sono. Formalmente o no, siamo tutti misurati e tutti capiamo il risultato.

Un'osservazione interessante è che il valore di un programmatore a volte passa inosservato finché non trova la squadra giusta. Allo stesso modo, un programmatore molto produttivo potrebbe puzzare in una squadra diversa. Penso che la produttività del team sia una misura più interessante ed è semplice: spediscono spesso, in tempo e senza problemi?

Steve McConnell, che ha scritto Codice completo, utilizza una Scala di sviluppo professionale .

Il livello principale, master , è definito come

The employee performs reference work in an area and has deep experience across multiple projects. The employee has generally taught seminars or classes or has written papers or books that extend the body of knowledge. The employee provides industry-level leadership and is recognized outside Construx [McConnell's company] for expertise in the area.

Ulteriori dettagli sul suo sito web

Ecco alcuni criteri che utilizzerei:

• Un buon programmatore in una determinata lingua capirà ogni singola riga nei suoi progetti in quella lingua (compresi i commenti), e può spiegare perché ogni linea è necessaria e cosa succederebbe se una linea fosse rimossa.
  Nessun incantesimo magico o utilizzo di appunti da carico.

• Un buon programmatore capirà come e quando le sue funzioni vengono chiamate da un codice esterno.
  (Quando si tratta di framework o threading dell'interfaccia utente)

Ho usato Dreyfus Modeling con molto successo in una serie di diverse abilità relative ai programmatori. Dreyfus Modeling guarda a cinque livelli di competenza:

• novizio
• principiante esperto
• competente (tendo ad usare "professionista")
• professionista esperto
• esperto

I due a cui prestare maggiore attenzione sono i livelli di novizio e di praticante. I novizi imparano seguendo le procedure passo dopo passo. I professionisti competenti sono sicuri di provare le cose da soli. È come guidare, in quanto si inizia in modo consapevole, seguendo le istruzioni. Alla fine ottieni la tua licenza. È ancora molto probabile che tu abbia un incidente, ma probabilmente non ucciderai nessuno. I professionisti esperti tendono a perdere tutto lo sforzo cosciente richiesto e gli esperti hanno una buona conoscenza della teoria coinvolta, magari insegnando o facendo qualcosa di straordinario con esso.

Di solito assegno i numeri da 1 a 5 a questi, per ottenere un risultato numerico. È molto utile utilizzare per misurare i risultati di istruttori e allenatori.

Puoi utilizzare questo modello per ogni aspetto della programmazione: TDD, integrazione continua, linguaggio, progettazione OO, ecc. Basta capire come le persone iniziano a provare un'abilità e cosa fanno in modo diverso quando hanno successo. Potrebbe essere necessario andare a cercare persone di successo per avere un'idea.

Una parola di cautela, però. Questo può essere usato solo come misura personale. Se provi a usarlo per dire, quante persone dovrebbero essere pagate, causerà l'inferno (ma credo che qualsiasi metrica lo farà comunque). Trovo che sia più utile utilizzare una tabella di marcia, insieme al coaching per aiutare le persone a capire dove desiderano imparare di più e quali risorse sono a loro disposizione per farlo.

Non credo sia possibile ottenere misurazioni accurate, a causa della capacità di far funzionare il sistema per farti sembrare migliore di te. Credo che se mantieni questa roba personale e privata e ti concentri sui punti di forza piuttosto che sulle debolezze, un team può migliorare rapidamente e in modo drammatico, ovunque sia partito.

Non sono riuscito a definire un elenco di qualità o campi di esperienza che definiscono un buon programmatore. Ma potrei sicuramente indicarne uno se avessi lavorato con loro per sei mesi.

Non so nemmeno se sia possibile codificarlo, ma scommetto che i team più affermati potrebbero chiedere a tutti separatamente la domanda "chi è il miglior programmatore qui" e darebbero tutti la stessa risposta.

In realtà, sarebbe un sondaggio davvero interessante da fare. Gli scienziati dovrebbero assolutamente andare d'accordo.

Sì e no. In teoria è possibile, in pratica, sospetto che non sia qualcosa che puoi fare in maniera efficiente (è un vantaggio che potresti trarre da ciò che avrebbe più che compensato il costo sostenuto nel farlo).

Ma per darti un esempio del tipo di problemi che devi affrontare, prova a definire "buono" (e in effetti "programmatore").

Varia da azienda a società e in effetti situazione a situazione. È la persona che fornisce la soluzione tecnicamente migliore? O la soluzione più veloce / più economica? O quello che rende il cliente più felice? O quello che rende la gestione più felice? E anche questo probabilmente dipenderà dal problema preciso in questo caso.

E mentre la persona è un programmatore, e se trovassero una soluzione davvero grande che è più nei regni dell'amministrazione di sistema (forse un prodotto di terze parti gratuito)? Direi che dovrebbe essere considerata un'ottima soluzione, ma scommetto che non si adatta bene alle metriche del programmatore.

Credo che la risposta dipenda dal tuo punto di vista: vuoi dire, un "buon programmatore" come collega, come qualcuno che lo sostituirà, come suo manager, come suo cliente ...

In qualità di programmatore, direi che la prima qualità è la perseveranza. Va bene se non sai tutto (chi lo fa, comunque? Sono piuttosto ignorante nelle scienze informatiche dal momento che non era quello che ho studiato inizialmente, quindi sono molto tollerante). Ma non cercare una soluzione è davvero qualcosa che mi infastidisce.

Quindi direi che un buon programmatore cerca sempre di risolvere i problemi. Un grande programmatore è qualcuno che ha passato molto tempo a farlo.

Il miglior segno di un programmatore buono o grande è uno, che presuppone sempre che ci sia qualcosa da imparare e da padroneggiare, e pratica una strong autodisciplina per assicurarsi che ogni fase del loro mestiere sia fatta bene ...

Per me è il desiderio di imparare, il desiderio di padroneggiare il tuo mestiere, e sono orgoglioso del tuo lavoro, e la capacità di visualizzare le conseguenze a lungo termine del processo che utilizzi.