¿Podría un representante interno, votación e insignias fomentar buenas prácticas de programación?

Solo pensando en voz alta: a los programadores nos encantan todas estas cosas de votación / insignias / representantes, por lo que podría introducirse un esquema como este en el proceso de revisión de código de las empresas para fomentar una mejor codificación.

Algo como

• Usted (u otras personas en su nombre) puede publicar una revisión (podría ser un fragmento, un solo compromiso o una serie de) para una revisión del código

• Otros pueden comentarlo (sería similar a las respuestas en SE)

• Se pueden dar / sugerir insignias (algunas serían buenas, otras serían malas como "Comentario Desierto" o algo así)

• Puede votar hacia arriba / abajo sobre el código en sí y los comentarios e insignias (por ejemplo, si alguien sugirió una insignia y usted estuvo / no estuvo de acuerdo)

El objetivo de un esquema como este sería

• Presente un poco de diversión para alentar el uso de revisiones de código

• Mejore la calidad (en este esquema, es probable que tanto el revisor del código como los revisores aprendan)

• Reduzca la posibilidad de que las revisiones de código provoquen 'guerras de ego'

• Proporcione algunas métricas para ayudar a medir el rendimiento individual.

¿Esto podría funcionar? Pensamientos?

La recompensa extrínseca como dinero, insignias o representante funcionará, a corto plazo , como las dietas y cualquier otro sistema basado en recompensas / castigos.

La recompensa intrínseca , como el propósito y la autonomía, debe usarse en su lugar y proporcionar resultados a más largo plazo. Es mucho más difícil ponerlo en práctica que los simples sistemas de recompensa extrínseca, pero vale la pena.

Muchos expertos investigaron sobre el tema. Aquí están mis dos favoritos:

Daniel Pink hizo una gran presentación en TED sobre el tema que es fácil de ver y entender.

Alfie Kohn , autor de Castigo por recompensas , escribió sobre el tema:

Claro, los sobornos y las amenazas pueden producir un cumplimiento temporal. Ofrezca una recompensa a los adultos por ir al gimnasio, oa los niños por recoger un libro, y puede funcionar por un tiempo. Pero llegan a pensar en sí mismos como motivados extrínsecamente, por lo que cuando la recompensa ya no está disponible, no hay razón para continuar. De hecho, pueden terminar menos interesados ​​en hacer ejercicio o leer que antes.

Otro problema con las recompensas (y los castigos) es que modificará el comportamiento de las personas. Por ejemplo, si le da un bono a su empleado, se centrará en obtener esos bonos, independientemente de los otros objetivos (de toda la empresa). Creará individualismo y competencia entre departamentos y empleados. El resentimiento tendrá lugar y todos mirarán a todos. Especialmente cuando uno de sus objetivos es "ayudar a medir el rendimiento individual".

El resto del empleado puede refutar las reglas del juego y renunciar. El aumento de la rotación se convertirá en un nuevo problema.

Tenga en cuenta que se han hecho muchas sugerencias sobre cómo mejorar la motivación en esta comunidad .

Si, podria

Pero solo si lo diseñas con mucho cuidado, de lo contrario podría ser contraproducente. He hecho algunos comentarios, pero pensé en resumir mi posición.

Para la reputación, el objetivo principal debe ser proporcionar una medida que los empleados puedan usar para rastrear su mejora de habilidades con el tiempo. Diseñe con mucho cuidado con eso en mente, lo difícil es encontrar buenas formas de medir la habilidad, no puedo hacerlo desde la cabeza.

Las insignias son principalmente una cosa "divertida", las mantendría principalmente alejadas y lejos de los problemas más orientados a las habilidades. Es decir, insignias como "esta semana noctámbulo" o un grupo "insignia enviada" estaría bien. Si tiene algunas insignias basadas en habilidades como "Se corrigieron la mayoría de los errores" o "Se reportaron la mayoría de los errores", piense detenidamente cómo se puede percibir y jugar. Las insignias deberían ser más sobre destacar el comportamiento que promocionarlo en la OMI. Asegúrese de tener insignias individuales y de equipo.

Recomiendo encarecidamente contra las insignias negativas, estas cosas deberían ser divertidas y hacer que las personas tengan miedo de cometer errores es peligroso. En su lugar, genere un correo electrónico útil y amigable para esos casos.

Recomiendo encarecidamente que no se les permita decidir y votar sobre las insignias. Las personas pueden enviar sus sugerencias de credenciales, pero dado que su efecto en las personas puede ser bastante severo, las credenciales que se utilizan deben tomarse por decisión cuidadosa de una persona que sepa lo que están haciendo y no por el voto mayoritario.

La revisión de códigos es una idea interesante y creo que es una de las formas en que podría generar un valor de habilidad. Destacar el código y discutirlo podría ser realmente útil. Sin embargo, podría ser contraproducente, si todos saben que están siendo juzgados potencialmente por todo lo que escriben, el desarrollo puede retrasarse. Especialmente con el desarrollo iterativo donde a veces escribes algo rápidamente y luego refactorizas, no quieres ese comportamiento.

Quizás eso podría ser compensado ya sea por la persona que envía el código o por otra persona que solo puede enviar el código de una determinada edad. Sin embargo, puede ser complicado saber qué efectos habrá

Al final creo que tendrás que probarlo y ver qué funciona y qué no, hay un buen libro llamado Reality is broken que podría ser interesante. También el libro de Daniel Pinks "Drive" es una lectura obligada.

En mi opinión, NO , ya que no mide la buena práctica en sí, sino un síntoma (si otros piensan que es una buena práctica).

Parafraseando un libro del tío Bob (olvidó el título): un buen código parece casi sin esfuerzo, hace que el problema parezca trivial, como si el lenguaje estuviera hecho para escribirlo.

En mi experiencia, dicho código pasa desapercibido, y solo después de mucho tiempo se hace notar que este código nunca causó problemas, y tal vez luego se recuerda, que el problema era, antes de la introducción del código, un gran lío de incertidumbre y vaguedad. El código que recibe elogios en las revisiones suele ser el que los revisores consideran en un buen día cuando no están de humor para molestar, y que tiene la menor cantidad de cambios.

La idea traería una nueva dinámica al equipo. Si siente que el equipo está en una rutina, esta es una buena manera de sacudir las cosas.

Solo recuerda que no serán todos unicornios y arcoiris. A algunos no les va a gustar la iniciativa, por lo que la productividad / calidad general puede verse afectada. Sin embargo, este riesgo puede valer la pena. Depende de tu situación.

Sugiero usar la motivación extrínseca (lo que está proponiendo es una forma de motivación extrínseca) para motivar a las personas a hacer cosas "mecánicas", repetitivas y aburridas, como:

• Llegar a tiempo a las reuniones
• Obtener hojas de tiempo enviadas a tiempo
• Actualización de documentación
• Compartir información con el equipo.

No lo usaría para motivarme en ningún tipo de trabajo que requiera creatividad, o donde la calidad no pueda medirse objetivamente. Por ejemplo, si tiene una persona que hace widgets y puede validar mecánicamente si una parte es buena o mala, y tiene un proceso que no permitirá que se realice una parte a menos que siga el proceso aprobado, entonces es productivo motivar el trabajador con recompensas extrínsecas por productividad porque el proceso no les permitirá tomar atajos para hacer más unidades a expensas de la calidad.

Si no tiene esas salvaguardas, entonces su intento de motivación extrínseca seguramente fracasará. La programación cae directamente en esta categoría: simplemente no podemos medir de manera confiable la calidad del software. Esto se debe a que cuando crea un widget, abandona la fábrica y no afecta el trabajo que realiza en el siguiente widget, pero cuando crea un software, debe seguir reelaborándolo una y otra vez. Las cosas que haces ahora tienen efectos a largo plazo. Son estos efectos a largo plazo los que son muy importantes pero no se pueden medir. La motivación intrínseca es un motivador mucho más útil para este tipo de cosas.

Eso significa:

• Deje que las personas se hagan responsables de su trabajo.
• Aliente a las personas a hablar entre sí sobre lo que funciona bien y lo que no.
• Mostrar un aprecio genuino por el trabajo de las personas.

Parte de lo que hace que esto funcione es la gran cantidad de participantes que no se conocen o que tienen que trabajar juntos todos los días. Creo que en un grupo pequeño, se convertiría más en una forma de jugar al sistema para que se vea bien o para que su competencia para la promoción se vea mal. Esta es la razón por la cual las evaluaciones formales entre pares son a menudo un sistema pobre. En un grupo pequeño, las personas con el mejor representante serán las más astutas políticamente, no las mejores programadoras.

La respuesta corta es sí, podría funcionar.

La respuesta un poco más larga es, sí, podría funcionar, pero también podría ser contraproducente.

Además de ser un programador profesional, también soy un analista de comportamiento aficionado.

Uno de los hallazgos característicos de la ciencia moderna del comportamiento es que el comportamiento está fuertemente influenciado por sus consecuencias.

Si controla las consecuencias, puede influir en el comportamiento hasta cierto punto. El grado depende de cuán importantes son las consecuencias específicas para cada individuo cuyo comportamiento está tratando de cambiar, y de cuán fácil es para ellos evitar sus consecuencias y encontrar a otros para quienes están dispuestos a trabajar.

Como programador profesional, una consecuencia de escribir código es que me pagan; deja de pagarme y dejaría de aparecer en poco tiempo. Pagar es una consecuencia realmente importante para mí (estoy criando una familia), y no hay otras consecuencias en mi compañía actual por las que estaría dispuesto a trabajar en lugar de recibir un pago.

Si fueras mi jefe, decidirías qué consecuencias (incentivos, refuerzos) ofrecerme. Pero no puedes decidir cómo los percibo. Por ejemplo, mi jefe podría decidir ofrecer un espacio de estacionamiento especial si soy seleccionado como "Codificador del mes". Si viviera en San Francisco o en la ciudad de Nueva York y condujera un automóvil, podría estar dispuesto a trabajar para eso. Pero donde vivo ahora, el estacionamiento no es un problema, y ​​puedo caminar al trabajo de todos modos.

En mi experiencia, el mayor riesgo que corre con la implementación de un programa como SO en el lugar de trabajo es que se le puede percibir como ofreciendo votos entre pares en lugar de pagar a las personas lo que valen.