¿Cómo convertir un programador de copiar / pegar / espagueti para ver la luz?

Esta pregunta fue inspirada por esta . Si bien esa otra pregunta se consideró localizada, creo que el problema subyacente es algo que es extremadamente común en nuestra industria. Sé que hay algunos desarrolladores, que leerán esto y pensarán que estoy inventando estas cosas y luego podrían responder cómo todos se preocupan por su trabajo y quieren aprender, pero solo mirando otras publicaciones de Programadores SE ( en este caso ), Sé que eso no es universalmente cierto.

Entonces, supongamos que tiene a alguien en su equipo (o tal vez la mayoría) cuyo procedimiento operativo estándar es copiar / pegar y que cree que todo se puede resolver si solo agrega suficientes llamadas a funciones y variables. Esta persona nunca escuchó hablar de TDD, SECO o SÓLIDO y fuera de 40 horas en el trabajo cuando está ocupado trabajando, nunca leyó una sola metodología / prácticas / libro de diseño.

En el pasado, yo (y otros) le pregunté cómo enseñarle OOD . Pero ahora estoy pensando que esa no es la pregunta correcta. La verdadera pregunta es ¿cómo te acercas a esa persona / equipo y haces que sientan curiosidad por una mejor manera de hacer las cosas? ¿Cómo los inspiras a aprender? Sin eso, parece que toda la enseñanza, reuniones, conferencias, discusiones son inútiles si están perfectamente felices de volver a su escritorio y hacer lo que siempre han hecho.

Trabajo con un montón de gente así. En realidad, son personas bastante brillantes, pero odio cuando escucho: "Ya terminé de codificar, solo necesito refactorizar y dividir en varias clases para hacer feliz a DXM". No refactorizan para obtener un código más limpio, legible y fácil de mantener, sino solo porque de lo contrario serán regañados. Sé que son capaces de aprender, solo parece que hay una falta general de motivación.

Cuando entrego trabajo, generalmente tiene muchos menos errores y el trabajo que poseía nunca se convirtió en una monstruosidad de 5000 líneas de una clase. Otros harán comentarios como, "su código es mucho más limpio y legible que nuestro material", por lo que ven la diferencia. Pero al mismo tiempo, creo que creen que les pagan 40 horas independientemente de lo que hagan, por lo que en realidad no les importa si pasan 3 días completos en QA buscando un error que no debería haberse introducido en El primer lugar. O que tardan una semana en modificar una clase porque hay tantas dependencias que terminan tocando. Sin embargo, "tal vez esa clase debería haberse escrito de manera diferente" nunca parece aparecer.

¿Se puede hacer algo en estas situaciones? ¿Alguien ha tenido éxito? ¿O es mejor aislar esa mentalidad en partes no críticas del proyecto y minimizar el daño?

NOTA: Cuando digo "falta de motivación". No creo que sea falta de motivación para trabajar o hacer un buen trabajo porque simplemente dejaron de preocuparse. La mayoría de nuestro equipo es todo lo contrario. Definitivamente se preocupan por el producto. Tenemos chicos que trabajarán noches y fines de semana. La parte que estoy tratando de superar es mejorar los hábitos y las habilidades, en realidad no tendrían que trabajar tanto. Supongo que lo de "40 horas" hizo que esta publicación sonara demasiado negativa.

Usted encontró la razón: "Sé que son capaces de aprender, solo parece que hay una falta general de motivación".

Hay personas apasionadas por su trabajo. Y hay otros que, siendo a veces lo suficientemente competentes, están trabajando solo por dinero . Saben lo que hacen, pero no disfrutan su trabajo. No pasarán más tiempo haciendo refactorización adicional para que el código sea legible o resolviendo un problema intrigante cuando un truco rápido y feo puede hacer el trabajo.

Este fenómeno existe en todos los trabajos. Es solo que algunos trabajos no son extremadamente emocionantes (¿has visto a un contador que ama su trabajo y ya lo soñó cuando era un niño?), Pero en la programación, hay muchas personas que realmente aman lo que están haciendo (de lo contrario Programadores.SE estará bastante vacío). Esto significa que, como desarrolladores apasionados, que hablamos a diario con otros desarrolladores apasionados, tenemos más oportunidades de sorprendernos al ver a una persona que programa solo por dinero.

¿Qué podemos hacer? No demasiado. En todos los casos, no es para usted, sino para los recursos humanos elegir personas verdaderamente motivadas¹. Y despedir a las personas que no lo son.

Puede intentar motivar a sus colegas usted mismo, pero es extremadamente difícil. Si les da libros para leer, los devolverán sin abrir unas semanas más tarde. Si les das un consejo, no escucharán, porque no les importa².

Usted puede:

• Convenza a su jefe para que establezca una serie de reglas estrictas en su empresa: pautas de estilo , etc. Esto no motivará a esas personas a hacer un mejor trabajo, pero al menos no podrán comprometer el código fuente que no cumple con los requisitos. .

• Trabajar en los requisitos, especialmente los requisitos no funcionales . ¿Qué pasa con un requisito que dice que un proyecto específico debe contener menos de 5 000 líneas de código IL (no, no estoy hablando del LOC sin sentido ) ³? ¿Qué pasa con la exigencia de obtener resultados específicos en la complejidad ciclomática o el acoplamiento de clases ?

• Aumente la cantidad de horas que pasa en su empresa haciendo revisiones de código . Especifique lo que se revisa: si tiene una lista de verificación, agregue los puntos relacionados con la refactorización, legibilidad, comentarios limpios y útiles, etc. Si no tiene una lista de verificación, debe hacerlo.

• Utilice [más] programación de pares . Puede ayudar a mejorar la calidad del código y motivar a los compañeros de trabajo menos motivados.

• Use el sistema de compensación similar al que se usa en Fog Creek.

^{¹ De eso se tratan las entrevistas: antes de contratarte, los recursos humanos deben valorar no solo tu nivel técnico, sino también tu motivación . Lamentablemente, algunas empresas se olvidan de esta segunda parte de la entrevista y contratan a personas que no disfrutan demasiado de la programación. Afortunadamente, en la mayoría de los casos, el trabajo en esas empresas nunca es agradable, y la prueba de Joel rara vez supera los 2.}

^{² Realmente no les importa, incluso si ganan menos dinero. Estoy bastante cerca de uno de mis clientes (soy un profesional independiente) que cree que su trabajo es desarrollar sitios web para sus propios clientes. Él también tiene un diseñador. Les dije muchas veces sobre las formas en que pueden aumentar su productividad en 2 o más. Si acabaran de contratar a alguien competente, aumentarían sus ingresos en al menos 3. Pero tienen suficiente dinero y no les importa la calidad o cuánto le cuestan a los clientes ignorantes, en comparación con alguien productivo.}

^{³ Lo que quiero decir es la cantidad de líneas de código IL que ves en Code Metrics en Visual Studio , la métrica que realmente significa algo. El verdadero LOC no importa y no tienes que medirlo; Es una de las métricas más estúpidas. Hacer cumplir las líneas de código IL significa que los desarrolladores se verán obligados a refactorizar el código, y no solo a colapsar diez líneas de código en una sola línea ilegible.}

"Ya terminé de codificar, solo necesito refactorizar y dividir en varias clases para hacer feliz a DXM".

Esa línea de pensamiento es que hay cáncer en cualquier equipo y matará la motivación de todo el equipo si no se atiende de inmediato. Me refiero, por supuesto, al hecho de que, por antigüedad y / o mérito, estás en una posición de autoridad técnica, dándote el poder de ayudar a influir y generar buenas prácticas en tu equipo.

Esto está muy bien, sin embargo, si su equipo se vendió claramente en estos procesos, no lo distinguirían en declaraciones como esta entre sí que muestran claramente una falta de respeto por el proceso y una falta de respeto en usted. Todavía ven estas mejores prácticas como un obstáculo causado por usted y no como un proceso propiedad del equipo que su equipo defenderá por sus propios méritos.

Usted menciona en comentarios anteriores que otros miembros del equipo siguen estas prácticas y estándares bien y los aplican correctamente. Primero, concentre la atención en reforzar su apoyo, pregúnteles qué funciona, qué no funciona, qué les gusta y qué les gustaría ver cambiado. Si hace esto y toma en serio sus opiniones, se sentirán de manera muy diferente acerca de los estándares, como si fueran una decisión de la comunidad en lugar de un procedimiento que un superior les haya transmitido.

Usted refuerza el soporte para las mejores prácticas y estándares al señalarle al equipo cómo han mejorado el proceso de desarrollo de software o la calidad del software.

Mantenga un voto sobre los asuntos para discusión y documente los resultados, idealmente, cada decisión debe ser unánime por el bien de la legitimidad, pero si se trata de obstruccionistas de línea dura, esto puede ser imposible y simplemente podría resolver todos los problemas. Use un voto mayoritario en esta situación. Si la mayoría está en contra de sus estándares y prácticas propuestas, entonces ya ha perdido el espacio, simplemente renuncie en ese punto.

Serán dueños de esos estándares y procedimientos y los harán cumplir para que usted no tenga que hacerlo. Como líder tecnológico, no debería tener que declarar edictos y decretos, esa es una mala manera de ser un líder.

Una vez que el equipo sienta que es el propietario de los procedimientos, los miembros del equipo que comiencen a etiquetarlo para ciertos procedimientos y mejores prácticas serán ilegítimos al pensar que sí. Su equipo ayudará a corregir esta actitud en los demás.

¡Buena pregunta! Creo que la respuesta depende de por qué las personas no quieren mejorar sus habilidades. Las posibles respuestas son:

• Piensan que están demasiado ocupados para aprender algo nuevo o piensan que la nueva forma de hacer las cosas (como escribir todas esas pruebas) les llevará más tiempo y no tienen tiempo para eso. Entonces la respuesta obvia sería: darles más tiempo. Aprender algo o probar algo como TDD cuando siempre has hecho las cosas de manera diferente te tomará más tiempo las primeras veces. Si sus programadores no tienen ese tiempo, no puede culparlos por no intentarlo.
• Tienen una percepción diferente de sus propias habilidades, es decir, piensan que son muy buenos programadores que producen código de alta calidad. Este es un terreno psicológico difícil, porque destruir esa creencia puede ser muy desmotivador. Quizás algún tipo de competencia informal puede ayudar (¿quién produce la menor cantidad de defectos / características? ¿El código más corto? ¿La menor cantidad de WTF / minuto en una revisión de código?).
• Puede haber un problema de motivación real (es decir, solo quieren "hacer su tiempo y quedarse solos" hasta la hora de cierre). Afortunadamente, esto es demasiado general / no está relacionado con la programación, porque realmente no tengo una respuesta para eso.
• Son principiantes y no saben mejor. En ese caso, la capacitación, las revisiones de códigos pueden ayudar, o un "club de lectura" donde un miembro del equipo tiene que discutir un nuevo libro técnico cada mes.
• Han visto balas de plata antes (y estaban muy decepcionadas) y piensan que lo que sea que estén tratando de vender es solo otra nueva palabra de moda que suena bien en teoría y es poco útil en la práctica. En ese caso, demostrar las ventajas durante las revisiones de código y las sesiones de programación de pares podría funcionar. Intenta no ser un sabelotodo total cuando hagas eso.

La mejor solución realmente depende del problema raíz: por ejemplo, las pautas formales de codificación, las métricas y las revisiones pueden funcionar para los principiantes, pero las personas con una "percepción errónea de sus propias habilidades", la gente podría luchar contra ellas o jugar las métricas porque ven ellos como obstáculos burocráticos contraproducentes para hacer su trabajo.

La verdadera pregunta es ¿cómo te acercas a esa persona / equipo y haces que sientan curiosidad por una mejor manera de hacer las cosas? ¿Cómo los inspiras a aprender? Sin eso, parece que toda la enseñanza, las reuniones, las conferencias y las discusiones son inútiles si están perfectamente felices de volver a su escritorio y hacer lo que siempre han hecho.

¡Eso es! De hecho, esta es una pregunta real.

Para dar algo de fondo, simplemente no tenemos tiempo para poner mucha capacitación formal , pero ocasionalmente si lo hago, todavía no veo luz. También he sido parte de las compañías donde la capacitación formal se convierte en un proceso en sí mismo y Soy tan a menudo testigo que apenas les enseñan a pensar.

Entonces, la pregunta que les hago no es cómo enseñarles , sino cómo hacer que aprendan. La diferencia es sutil, pero es lo que hará toda la diferencia.

No sé si tengo razón; pero a menudo creo en un diálogo de una película de Matrix : "¡Es la pregunta la que nos impulsa!" ¡Lo más importante es hacerlos pensar, hacerles preguntar por qué! Y, por supuesto, la mayoría de los que piensan que ya saben todo sobre algunos patrones de diseño porque obtuvieron buenas calificaciones en los cursos universitarios, son los más difíciles allí.

¿Cómo se les hace hacer esas preguntas? Mi enfoque general es "tirarlos al estanque si quieres que aprendan a nadar" . Estoy de acuerdo en que las personas pueden estar en desacuerdo; y con mucho gusto acepto estar en desacuerdo con ellos. Cuando los arrojas al estanque, en realidad no aprenden a nadar automáticamente; pero provoca un instinto de supervivencia que los hace pensar: una vez que eso ocurra, naturalmente pensarán en CÓMO y POR QUÉ.

Un ejemplo práctico que le doy a la gente es ponerlos en un proyecto significativamente complejo de lo que esperaban para obtener uno y dejarlos pelear su propia batalla. A medida que comenzaron a desentrañar el código y les resulta difícil rastrearlo, te das cuenta de que comienzan a hacer una buena pregunta.

Esto puede sonar un poco extremista, esto puede parecer una pérdida de recursos . Y estoy seguro, hay muchos otros que me darán el consejo de no hacer esto. ¡Pero esto me ha funcionado!

No importa qué paquetes de pago y etiquetas de recursos humanos que le asigne no resolverá el problema de motivación básica . Porque ese único camino es que son desafiados; Si chispas de este espíritu humano básico, todo lo demás funciona. Si no puedes, es un juego suelto suelto.

PD: Por cierto, publiqué una respuesta aquí https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - y obtuve todos los ataques; ¡Principalmente la mayoría de la gente cree que de alguna manera las empresas no pueden permitirse el lujo de desperdiciar recursos! Estoy seguro de que esta respuesta puede recibir un tratamiento similar aquí. Pero la verdad es que hacer que las personas trabajen y hacer que crean en un buen trabajo es un tema de la psicología humana sobre cómo elaborar el programa del curso.

De todos modos, la tarea que está describiendo aquí equivale a encender la pasión interior para hacer un gran cambio. Y cuanto más grande es el sistema, más difícil se vuelve. Comience con compañeros más jóvenes que todavía están integrados con el espíritu de " no quiero hacer un buen trabajo " y desafía el status quo.

Como señalas, es motivación. No los confundas sin preocuparse por ellos sin saberlo. Ellos claramente saben qué hacer. Simplemente no les importa . Si ese es el caso, la verdadera pregunta aquí es ... ¿qué está haciendo mal su administración que los mantiene tan desmotivados? ¿Eres el miembro más nuevo del equipo? Tal vez ya hayan pasado por todo esto antes, y esto solo ha generado problemas por parte de su administración. Por lo tanto, se limitan a hacer la menor cantidad de trabajo necesaria para mantener su trabajo porque no creen que el empleador responda a hacer más.

Me parece que este es un problema de gestión y liderazgo: si es su equipo, entonces puede trabajar para que la mejora (personal y del código) sea un atributo central de su equipo, la pregunta es si su gerencia lo respaldará , porque querrá hacer cosas que llevarán tiempo (obtendrán una ganancia neta ya que debería reducir la nueva deuda técnica y pagará la deuda técnica existente).

Entonces, usted afirma que desea que el equipo mejore, obtiene su acuerdo de que esto es algo bueno (que el equipo, en su conjunto, trabaja para mejorar la calidad de su código) y luego comienza un programa para hacer esto sucede - suena tan fácil ... ¡Sé que no lo es!

Creo que esto tiene dos partes: educación y prácticas laborales.

• Puede comenzar una hora de almuerzo a la semana: todos comen juntos, usted realiza una presentación de 20 a 30 minutos con preguntas y respuestas. Empiezas con lo básico que deseas: SOLID puede ocupar las primeras 2 ~ 4 semanas; con el tiempo, haces que el equipo hable por turnos y puedes determinar cómo decidir quién habla sobre qué entre ustedes. Permita que los oradores tengan tiempo de preparación en el trabajo. Más allá de eso, fomente la asistencia de grupos de usuarios locales (haciéndolo al menos parcialmente social si es posible)
• Prácticas de trabajo ... bueno, depende de lo que haga ahora y de las herramientas que tenga, pero es posible que desee ver los estándares de codificación de acuerdo, la introducción de la revisión del código de pares (es sólido), la prueba unitaria (no necesariamente la prueba primero) , ejecutando un servidor de integración continua y buscando pruebas más automatizadas (además de las pruebas unitarias). Pero estos tienen que introducirse sustancialmente con consentimiento / acuerdo (¡no el servidor de compilación / CI!) Y debe querer impulsar la calidad como equipo. Siempre hay cosas que uno puede mejorar (Kaizen)

También vale la pena mirar a Kanban (que es visto como un controlador para el cambio / mejora).

Un último pensamiento: soy un programador vocacional y me gustaría que mi equipo sea el mismo, pero trabajar más de 40 horas a la semana no es algo bueno, por lo que el objetivo debería ser tener un equipo que haga su trabajo efectivamente y bien dentro de la semana laboral normal y con respecto a esto, el argumento para mejorar la práctica laboral es que es más probable, por ejemplo: agregar pruebas unitarias para demostrar el caso de falla cuando (antes) la corrección de errores le da la confianza de que esfijo; tener un servidor de compilación le da confianza en su capacidad para construir sus soluciones de manera limpia: si esa compilación también genera paquetes de implementación, significa que la implementación se simplifica dramáticamente; El código SOLIDO es, por definición, más fácil de modificar; y en general, cuanto menos deuda técnica tengas, menos tendrás que pagar ...

Caí en la programación por accidente ~ hace 30 años. Estaba motivado para aprender los principios básicos de ingeniería de software al ser asignado para mantener / apoyar el código de otras personas. En estas tareas, aprendí cómo un lector de código experimenta el código, cómo empatizar con el lector de código. ¡No quería infligir el dolor de mi código mal escrito a otros!

Esta práctica de asignar nuevos programadores para mantener / apoyar el código de otras personas no es una bala mágica, y parece proporcionar motivación para aprender a producir código sólido la mayoría de las veces.