Un rappresentante interno, votazioni e badge potrebbero incoraggiare buone pratiche di programmazione?

Basta pensare ad alta voce: noi programmatori adoriamo tutte queste cose di voto / badge / rep, quindi uno schema come questo potrebbe essere introdotto in un processo di revisione del codice delle aziende per incoraggiare una migliore codifica.

Qualcosa di simile a

• Tu (o altri per vostro conto) potete pubblicare una recensione (potrebbe essere snippet, commit singolo o serie di) per una revisione del codice

• Altri possono commentarlo (sarebbe simile alle risposte in SE)

• I badge possono essere dati / suggeriti (alcuni sarebbero buoni, alcuni sarebbero cattivi come "Comment Desert" o altri simili)

• Puoi votare su / giù il codice stesso, i commenti e i badge (ad es. Se qualcuno ha suggerito un badge e hai accettato / meno)

L'obiettivo di uno schema come questo sarebbe

• Introdurre un po 'di divertimento per incoraggiare l'uso delle recensioni di codice

• Migliorare la qualità (in questo schema è probabile che sia il revisore del codice sia i revisori imparino)

• Ridurre la possibilità che le revisioni del codice scatenino "guerre dell'ego"

• Fornisci alcune metriche per aiutare a misurare le prestazioni individuali

Potrebbe funzionare? Pensieri?

La ricompensa estrinseca come denaro, badge o rappresentante funzionerà, a breve termine , come le diete e qualsiasi altro sistema basato sulla ricompensa / punizione.

Dovrebbero invece essere utilizzati premi intrinseci , come scopo e autonomia, e risultati più a lungo termine. È molto più difficile metterlo in pratica rispetto ai semplici sistemi di ricompensa estrinseca, ma paga.

Molti esperti hanno fatto ricerche sull'argomento. Ecco i miei due preferiti:

Daniel Pink ha fatto un'ottima presentazione al TED sull'argomento che è facile da guardare e capire.

Alfie Kohn , autore di Punished by Rewards , ha scritto sull'argomento:

Certo, tangenti e minacce possono produrre una conformità temporanea. Offri una ricompensa agli adulti per andare in palestra o ai bambini per aver preso un libro e potrebbe funzionare - per un po '. Ma arrivano a pensare a se stessi come estrinsecamente motivati, quindi quando la ricompensa non è più disponibile non c'è motivo di continuare. In effetti, potrebbero finire per essere meno interessati all'esercizio o alla lettura di quanto non fossero prima.

Un altro problema con i premi (e le punizioni) è che modificherà il comportamento delle persone. Ad esempio, se dai un bonus al tuo dipendente, questi si concentreranno sull'ottenimento di tali bonus, indipendentemente dagli altri obiettivi (a livello aziendale). Creerà individualismo e competizione tra dipartimenti e dipendenti. Il risentimento avrà luogo e tutti guarderanno tutti. Soprattutto quando uno dei tuoi obiettivi è quello di "aiutare a misurare le prestazioni individuali".

Il resto dell'impiegato può confutare le regole del gioco ed uscire. L'aumento del fatturato diventerà quindi un nuovo problema.

Si noti che molti suggerimenti su come migliorare la motivazione sono stati fatti in questa comunità .

Sì, potrebbe

Ma solo se lo progetti con molta attenzione, altrimenti potrebbe ritorcersi contro. Ho fatto alcuni commenti ma ho pensato di riassumere la mia posizione

Per la reputazione l'obiettivo principale dovrebbe essere quello di fornire una misurazione che i dipendenti possano utilizzare per tenere traccia del miglioramento delle loro abilità nel tempo. Progettalo con molta attenzione pensando a ciò, la cosa difficile è trovare buoni modi per misurare l'abilità, non posso farlo dalla cima della mia testa.

I badge sono principalmente una cosa "divertente", li terrei principalmente lontano e lontano da problemi più orientati all'abilità. Vale a dire badge come "nottambulo di questa settimana" o un gruppo "Distintivo spedito!" Sarebbe ok. Se disponi di alcuni badge basati sull'abilità, come "Risolto il problema con la maggior parte dei bug" o "Segnalati la maggior parte dei bug", rifletti attentamente su come potrebbe essere percepito e giocato. I badge dovrebbero riguardare maggiormente l'evidenziazione del comportamento piuttosto che promuoverlo dall'IMO. Assicurati di avere badge sia di squadra che individuali.

Consiglio vivamente contro i badge negativi, queste cose dovrebbero essere divertenti e rendere le persone spaventate dal commettere errori è pericoloso. Genera invece un'e-mail utile e amichevole per questi casi.

Consiglio vivamente di non lasciarli decidere e votare i badge. Le persone possono inviare i loro suggerimenti per i badge, ma poiché il loro effetto sulle persone può essere piuttosto grave, i badge utilizzati devono essere effettuati con un'attenta decisione di una persona che sa cosa stanno facendo e non il voto della maggioranza.

Le revisioni del codice sono un'idea interessante e immagino uno dei modi in cui potresti generare un valore di abilità. Evidenziare il codice e discuterne potrebbe essere davvero utile. Tuttavia, potrebbe essere controproducente, se tutti sanno di essere giudicati su tutto ciò che scrivono lo sviluppo potrebbe rallentare a una scansione. Soprattutto con lo sviluppo iterativo in cui a volte scrivi qualcosa velocemente e poi rifletti che non vuoi quel comportamento.

Forse ciò potrebbe essere compensato dalla persona che invia il codice stesso o da qualcun altro che è in grado di inviare il codice di una determinata età. Tuttavia può essere difficile sapere quali effetti ci saranno

Alla fine penso che dovresti provarlo e vedere cosa funziona e cosa no, c'è un buon libro chiamato La realtà è rotto che potrebbe essere interessante. Anche il libro di Daniel Pinks "Drive" è assolutamente da leggere.

A mio avviso, NO , in quanto non misura la buona pratica stessa, ma un sintomo (se altri la pensano buona pratica).

Per parafrasare un libro di Zio Bob (dimenticato il titolo): un buon codice sembra quasi senza sforzo, fa sembrare banale il problema, come se il linguaggio fosse stato creato per scriverlo.

Nella mia esperienza, tale codice non viene annotato e solo dopo molto tempo viene a conoscenza che questo codice non ha mai creato problemi e forse si ricorda che il problema era, prima dell'introduzione del codice, un enorme casino di incertezza e vaghezza. Il codice che ottiene elogi nelle recensioni è in genere quello che i revisori guardano in una buona giornata quando non sono in vena di fare le chiacchiere, e che ha il minor numero di modifiche.

L'idea avrebbe portato una nuova dinamica al team. Se ritieni che la squadra sia in agitazione, questo è un buon modo per scuotere le cose.

Ricorda solo che non saranno tutti gli unicorni e gli arcobaleni. Ad alcuni non piacerà l'iniziativa, quindi la produttività / qualità complessiva potrebbe risentirne. Tuttavia, questo rischio può valerne la pena. Dipende dalla tua situazione.

Suggerisco di usare la motivazione estrinseca (quello che stai proponendo è una forma di motivazione estrinseca) per motivare le persone a fare cose che sono "meccaniche", ripetitive e noiose, come:

• Presentarsi in tempo alle riunioni
• Ricevere schede attività in tempo
• Aggiornamento della documentazione
• Condivisione delle informazioni con il team

Non lo userei per la motivazione su qualsiasi tipo di lavoro che richiede creatività o dove la qualità non può essere misurata in modo obiettivo. Ad esempio, se hai una persona che crea widget e puoi validare meccanicamente se una parte è buona o cattiva e hai un processo che non consente di realizzare una parte a meno che non segua il processo approvato, allora è produttivo motivare il lavoratore con ricompense estrinseche per la produttività perché il processo non consentirà loro di prendere scorciatoie per creare più unità a scapito della qualità.

Se non disponi di tali garanzie, il tuo tentativo di motivazione estrinseca sicuramente fallirà. La programmazione rientra esattamente in questa categoria: non possiamo misurare in modo affidabile la qualità del software. Questo perché quando si crea un widget, questo lascia la fabbrica e non influisce sul lavoro svolto sul widget successivo, ma quando si crea un software, è necessario continuare a rielaborarlo più e più volte. Le cose che fai ora hanno effetti a lungo termine. Sono questi effetti a lungo termine che sono molto importanti ma che non possono essere misurati. La motivazione intrinseca è una motivazione molto più utile per questo tipo di cose.

Questo significa:

• Lascia che le persone si assumano la responsabilità del proprio lavoro
• Incoraggia le persone a parlarsi di ciò che funziona bene e di ciò che non funziona
• Mostra sincero apprezzamento per il lavoro delle persone

Parte di ciò che rende questo lavoro è il gran numero di partecipanti che non si conoscono o devono lavorare l'uno con l'altro ogni giorno. Penserei che in un piccolo gruppo, sarebbe più un modo per giocare al sistema per apparire bene o per far sembrare cattiva la concorrenza per la promozione. Questo è il motivo per cui le valutazioni formali tra pari sono spesso un sistema scadente. In un piccolo gruppo le persone con il miglior rappresentante saranno quelle che sono i più astuti politicamente, non i migliori programmatori.

La risposta breve è, sì, potrebbe funzionare.

La risposta leggermente più lunga è, sì, potrebbe funzionare, ma potrebbe anche ritorcersi contro.

Oltre ad essere un programmatore professionista, sono anche un analista del comportamento amatoriale.

Una delle scoperte distintive della moderna scienza comportamentale è che il comportamento è fortemente influenzato dalle sue conseguenze.

Se controlli le conseguenze, puoi influenzare il comportamento in una certa misura. Il grado dipende da quanto importanti conseguenze specifiche sono per ogni individuo il cui comportamento stai cercando di cambiare e da quanto sia facile per loro evitare le tue conseguenze e trovare gli altri per i quali sono disposti a lavorare.

Come programmatore professionista, una conseguenza della scrittura del codice è che vengo pagato; smettere di pagarmi e smetterei di presentarmi in poco tempo. La retribuzione è una conseguenza molto importante per me (sto crescendo una famiglia), e nella mia attuale azienda non ci sono altre conseguenze per le quali sarei disposto a lavorare invece di essere pagato.

Se tu fossi il mio capo, dovresti decidere quali conseguenze (incentivi, rinforzi) offrirmi. Ma non puoi decidere come li percepisco. Ad esempio, il mio capo potrebbe decidere di offrire un parcheggio speciale se sono selezionato come "Coder of the Month". Se vivessi a San Francisco o New York City e guidassi una macchina, potrei essere disposto a lavorare per quello. Ma dove vivo adesso, il parcheggio non è un problema e posso comunque andare a piedi al lavoro.

Nella mia esperienza, il rischio più grande che corri nell'implementare un programma come SO sul posto di lavoro è che potresti essere percepito come offrire voti paritari al posto di pagare alle persone ciò che valgono.