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

35

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.

DXM
fuente
Que pais es este
3
@ ThorbjørnRavnAndersen - Estados Unidos. ahora tienes que escribir una respuesta porque tengo mucha curiosidad de cómo esa información la afectó :) Siempre pensé que todos éramos humanos y este tipo de cosas era universal. Y no, esta pregunta no tiene nada que ver con la contratación externa.
DXM
8
Las diferencias culturales entre países pueden ser sustanciales, y cualquier intento de introducir cambios debe tener esto en cuenta. Lo que funciona en una cultura probablemente no funcionará en otra. En su caso, creo que la mejor manera es hacer que la gerencia eleve oficialmente el listón de lo que es aceptable.

Respuestas:

18

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.

Arseni Mourzenko
fuente
3
No estoy de acuerdo: la motivación para trabajar y la motivación para aprender son dos cosas completamente distintas. Por ejemplo, algunas personas aman su trabajo y el trabajo, pero podrían pensar que "SOLIDO" es solo otra palabra de moda de bingo de mierda o "TDD" es un concepto de torre de marfil sin uso en el mundo real.
nikie
55
@maple_shaft tiene razón: algunas personas trabajan 70 horas por semana y producen la peor cantidad de código de espagueti sin ninguna prueba (¡no tienen tiempo para esas tonterías!). Si bien son apasionados y mejoran constantemente sus habilidades, se van a casa después de 40 horas, porque saben que de todos modos no pueden ser productivos más que eso. ¡No mezcles las dos cosas!
nikie
13
No no no. Voluntad de ser explotado por un empleador! = Capacidad de producir código de calidad. Ya hay demasiadas tonterías de "quedarse hasta las 2 de la mañana para hacerlo" en nuestra industria sin que eso se confunda con un mítico desarrollador ideal. Si te encanta trabajar 80 horas a la semana, más poder para ti. Tengo cosas que son importantes para mí además del trabajo. Para concluir, soy malo en lo que hago porque eso es falso en el mejor de los casos. Ninguna otra industria se sale con la nuestra, y depende de nosotros cambiar eso, si va a cambiar.
Dan Ray
66
Tener que trabajar hasta las 2 AM para trabajar en un proyecto es una forma muy eficiente de matar cualquier amor por dicho proyecto, especialmente para aquellos con obligaciones familiares.
2
Creo que todos los puntos presentados aquí son válidos, pero algunos de ustedes pueden haber malinterpretado MainMa. Él nunca dijo trabajar hasta las 2 de la mañana porque te obligan debido a los plazos. En cambio, simplemente se refirió a las personas que están tan atrapadas en la emoción de ver que algo funciona, que a veces prefieren hacerlo antes de irse a dormir. Me identifico con esto. Para mí, un ejemplo extremo fue una tarea en la que estaba trabajando para agregar soporte de túnel a nuestra biblioteca de transmisión de video. Se estimó en 5 días, pero con nuestra nueva arquitectura de tuberías, todo se estaba juntando tan bien, comencé el viernes por la tarde ...
DXM
12

"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.

árbol de arce
fuente
1
1 para el énfasis en las relaciones centrándose en lugar de principios
sunwukung
5

¡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.

nikie
fuente
Buenos puntos. Especialmente me gusta el primero, e incluso generalizaría: primero debe dejar en claro que se fomenta el aprendizaje en el trabajo y que está bien reservar tiempo explícitamente para ello.
sleske
Si las personas tienen una percepción diferente de sus habilidades, ¿tal vez solo están midiendo el éxito en diferentes parámetros? Si está midiendo la calidad del código y está pensando en qué tan rápido se puede crear el código, obviamente el resultado será diferente; en este tipo de casos, debería preguntar cómo miden el éxito. Diferentes personas tienen diferentes maneras de pensar sobre esto.
tp1
3

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.

Dipan Mehta
fuente
gracias por mencionar la matriz, ahora tengo que pasar 2 horas de mi vida viéndola de nuevo :) Es divertido, pero descubrí que los "más frescos" son los que absorberán todo lo que les arrojes. Después de haberme graduado de un excelente programa de CS, dejo muy en claro lo que pienso de su "educación" y, en general, están de acuerdo conmigo. Me parece que los problemas más importantes son los que han estado haciendo esto durante 10, 15, más de 20 años. También estoy de acuerdo con su enfoque de "prueba de fuego". Así es exactamente como aprendí lo que no debía hacer. El problema es a) lleva mucho tiempo que la mayoría de los equipos no pueden permitirse yb) cuando trabajan en un equipo ...
DXM
.. configuración (me atrevo a decir "semi-ágil", no me odies S.Lott :)), no tenemos la propiedad exclusiva, que requiere prueba por fuego. Si escriben algo que falla, alguien intervendrá y lo arreglará. Como alguien que ha estado en el estanque y en su mayoría logró salir, me gustaría pensar que tenía curiosidad por saber si se podría hacer algo para transferir esa mentalidad sin que todo su equipo atraviese el estanque.
DXM
@DXM Estoy de acuerdo con sus inquietudes de que es mejor no tirar a todo el equipo al estanque de una vez. Sí. El punto es, ¡comienza a tirar algunos de ellos uno por uno! Al menos ese es un buen acuerdo entre nosotros. Creo que la mentalidad que ha crecido durante muchos años requerirá algo de tiempo y perseverancia para cambiar.
Dipan Mehta
@DXM para darle cosas más concretas - pruebe pequeñas iniciativas a la vez - muestre los logros y demuestre que la administración significa negocios para hacer un buen trabajo aquí. Y promueva la mentalidad, paso a paso. la persistencia sería imprescindible, pero lo había logrado en mi última compañía. Con el tiempo, la gerencia siguió dando a mi equipo un ejemplo de cómo hacerlo bien.
Dipan Mehta
1
Me gusta su respuesta, especialmente si funciona para usted, por lo que lo siguiente no es una crítica, sino solo una nota: lamentablemente, esto no funciona en todos los casos. Tuve varios casos donde los desarrolladores no motivados comenzaron grandes proyectos. Terminó de la misma manera cada vez: el proyecto falló y culpó a la gerencia o sus colegas o al hecho de que no había suficiente tiempo o recursos o que los requisitos no eran lo suficientemente claros. Me pregunto qué hace la diferencia entre aquellos que aprenderán a nadar y aquellos que probablemente culparán al agua.
Arseni Mourzenko
2

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.

Gran maestro B
fuente
Soy el líder del equipo y he estado con el equipo durante casi 9 años, pero obtuve el liderazgo hace aproximadamente un año. Creo que hay una diferencia entre "no me importa el trabajo o la calidad de mi código" y "no me importa aprender nuevas habilidades". De hecho, hemos realizado muchas mejoras en el lado de la administración y muchos de nuestros compañeros de equipo ahora están muy contentos. Sin embargo, algunos están bastante contentos haciendo lo que siempre han hecho. De hecho, dedicaron horas adicionales sin siquiera preguntar, muy receptivos, pero todavía parecen bastante contentos depurando sus propios errores el 75% del tiempo.
DXM
1
Bueno, entonces, como en toda profesión, no todos estarán en la mitad superior de la curva de la campana. Es posible que solo tengas algunas personas solo por el sueldo.
GrandmasterB
Sabes, cada año elegimos una cita del equipo y el 2011 fue "es lo que es", pero estamos a punto de comenzar un nuevo año y, al menos por el momento, me negaré a aceptar que es lo que es, aunque estoy de acuerdo contigo en que la mayoría de las veces lo es realmente. He estado pensando más sobre esta pregunta y realmente tengo una idea que podría tener potencial. Como no puedo responder a mi propia pregunta (cosa personal, no limitación del sistema), si 2 personas más votan para volver a abrir programmers.stackexchange.com/questions/127080/… Publicaré allí :)
DXM
2

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 ...

Murph
fuente
0

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.

David Pointer
fuente
1
Empecé de la misma manera, aunque no por casualidad. Esto es muy similar a lo que dijo Dipan Mehta en su publicación. Tiras a una persona en un estanque, asegurándote de que no sea demasiado profunda, y la dejas nadar. Usted fue uno de los que aprendió a nadar, pero eso no es universal (vea su respuesta con comentarios). También creo que este tipo de enfoque funciona mejor para las personas nuevas que las que ya tienen hábitos arraigados. Entonces, no solo necesitan nadar, sino que también está en contra de la corriente de las prácticas establecidas.
DXM