¿Cómo hago para que las personas dejen de andar en bicicleta (centrándose en las trivialidades)?

Creo que el problema es la tarea: "Me encargaron de enseñar un nuevo código base a otros equipos".

Se le ha asignado el trabajo incorrecto, o tal vez malinterpretado el trabajo que se le ha dado.

Al presentar a nivel de código, invitas a pensar a nivel de código.

Comience en el nivel del sistema y presente el diseño y las elecciones de diseño que se hicieron. No permita una discusión prolongada: no la está revisando. Permita preguntas: quiere que comprendan el sistema. Si la gente "lo hubiera hecho de otra manera", está bien. Tal vez de acuerdo. O no. Pero sigue adelante. Es la forma en que está ahora.

Cuando llegue al nivel de código, ya los habrá preparado con la terminología del sistema. Los nombres (supongo) tendrán sentido. Lo mismo que arriba: no hay discusión extendida, preguntas para entender. Seguir adelante.

Ahora configura algunos problemas de clase para resolverlos. ¿Cómo podemos hacer la mejora X? Elija algo no trivial que "vaya con el flujo" del diseño del sistema y trabaje en lo que cambiaría. Deben estar recibiendo la lógica del sistema ahora. Elija otra mejora que podría romper el sistema si se hace mal, y muestre cómo puede hacerse correctamente. Ese debería ser un momento Ah Ha para ellos. ¡Algunos podrían incluso vencerte!

Es un concierto difícil, especialmente después del falso comienzo que has tenido. Parece que ya has invertido mucho tiempo y esfuerzo, y tal vez hay un poco de sentimiento de "yo contra ellos". 'Fess up, y empezar de nuevo. Asumimos que son personas inteligentes. Dales el desafío de pensar en el nivel superior. Y rompa los grupos que ya existen seleccionando diferentes secciones de equipos para las nuevas sesiones.

"Aparcarlos". Al comienzo de la lección, explique qué es lo que debe debatir y explique claramente qué se considera Fuera de tema. Si le hacen una pregunta que es claramente OT, dígalo y continúe. Si regresan a ella, escriba la pregunta en una pizarra (esto es fundamental) para una discusión posterior y continúe. Al final de la lección, cuando estén en su propio tiempo, no en el tuyo, observa qué tan rápido se resuelven esas preguntas.

Establezca las expectativas correctamente y sea honesto, abierto y directo.

Asegúrese de que sus objetivos sean abiertos y transparentes.

Comience las discusiones con la vista de alto nivel promovida por andy256 (+1), pero también asegúrese de incluir sus objetivos, por ejemplo,

"... al ver este problema, asegurémonos de no enfocarnos en x, y y z. También asegurémonos de que no estamos viendo detalles de implementación como a, b, c o detalles triviales como j, k, l. Sé que es probable que haya muchos detalles en el código y detalles que podrían abordarse, mejorarse o hacerse más estándar, pero tratemos de ver lo que realmente está logrando a un nivel superior primero "

  

Entonces, ¿cómo educas a otros programadores lo suficiente para que dejen de fijarse en las trivialidades y puedan contribuir de manera significativa al diseño?

Primero, no pienses en sus preocupaciones como "trivialidades" o "motociclismo". Esas son palabras de juicio, y son insultantes. Sus inquietudes son válidas. Simplemente no son importantes en este momento.

La clave para cualquier buena reunión es que todos la conozcan:

• por qué estás teniendo una reunión y
• lo que esperas obtener de él
• cuánto debe durar

Indique estas cosas por adelantado, explícitamente, y explique los objetivos.

Por ejemplo, podría decir: "Esta reunión es para que me familiarice con el paquete de Foo y cómo se usa en nuestro módulo de informes. Mi objetivo es que entienda lo suficiente sobre Foo que pueda trabajar en los Informes de barra. el proyecto se acerca la próxima semana. Me gustaría que terminemos en los próximos 90 minutos ".

Entonces, cuando surge un tema, podría ser así:

  

Nueva persona: "¿Por qué se implementa FooWidget como un patrón de fachada?"

     

Usted: "Bueno, creo que es porque (breve explicación de la decisión de diseño)" o "No sé".

Si la respuesta es suficiente, eso es genial. Si no, y continúa:

  

NP: "¿No crees que sería mejor hacerlo como un singleton?"

     

Tú: "Realmente no lo había pensado, pero me gustaría seguir avanzando explicando cómo funciona FooWidget".

     

NP: "Pero si se hace como un singleton, entonces podemos--"

     

Usted: "Lamento interrumpir, pero necesito mantener esto enfocado en cómo funciona FooWidget. Esta reunión solo está programada hasta las 11:00 y tenemos mucho que superar. La discusión sobre el diseño tendrá que esperar para otro momento. "

Después de que lo repitas una o dos veces, puedes abreviar a "Eso está fuera del alcance de esta reunión".

Tenga en cuenta que no está diciendo "Es tonto preocuparse por eso" o "No importa" o "Cállate" o "Eres demasiado nuevo para recibir comentarios". Simplemente está enfocando la reunión en lo que se necesita hacer y el tiempo necesario.

En cierta organización, nunca podrás lograr esto. Muchas organizaciones valoran las disputas políticas y la escalada de manera más que la capacidad intelectual, la diligencia y la lealtad. ¿Y por qué no? La escalada de escaleras coloca a las personas en posiciones de poder, les permite mejorar sus vidas personales con un ingreso más discrecional y realmente nunca se vuelve obsoleta.

Contraste esta disputa de poder con la resolución real de problemas, el pensamiento abstracto y la toma de decisiones sobre problemas difíciles de los que pueden ser responsables las consecuencias más adelante, y muchos empleados tienen mucho peso por el lado de tratar de usar la bicicleta lo más posible.

El único consejo que sugiero es que deje en claro, en el contexto de su organización, si es posible, que estos participantes destino personal dependen de su comprensión, contribución, y esfuerzo hacia el problema real que estás tratando de resolver. Si esa es la arquitectura de la empresa, expresada en esta base de código -errant y todas sus fallas, eso es todo. Déjales en claro que deben proporcionar una información sustancial y significativa sobre que . No es otro tipo de aleatoriedad, que es el motivo de una mascota u otra persona mayor y que obtendrá buenos puntos de brownie al estar de acuerdo con dicha persona mayor.

Esto a menudo es difícil de hacer, ya que la persona mayor generalmente no entiende la tecnología, no está interesada y, por desgracia, controla los ingredientes básicos: el tiempo de los empleados; contratar & incendio, política de sala de conferencias, promociones, etc., etc. en serio, etcétera hasta el nth.

Lo que llamas motociclismo, lo llamaría convertir el flujo de pensamientos de alguien en el nuestro. Al hablar de nombres y patrones, pueden entender el código en sus propios términos y no hay forma de evitarlo, es necesario.

Además, no es necesario ir a un tutorial muy detallado de una base de código completa, porque los detalles se olvidarán mucho antes de que trabajen en él.

Sobre la base de estas dos ideas, sugeriría dividir la base del código en unidades y los alumnos en grupos de dos personas. Para cada unidad de código, cada grupo tendrá, por ejemplo, 25 minutos (depende de LOC , por supuesto), para poder Para hacer un recorrido de 5-10 minutos del código a los demás. Tres minutos de preguntas y repetir con la siguiente unidad. Explicar es la palabra clave; tienen que asegurarse de que los demás lo hayan entendido todo.

Solo estaría allí para hacer cumplir el tiempo, no se ha entendido lo suficiente el tema ajeno y el control de la unidad. Serán actores de su aprendizaje y estarán más centrados en explicar a los demás que en el ciclismo.

Es posible que necesite un esquema dibujado a mano de alto nivel de la unidad de código, que se copiará y conservará en los documentos compartidos por el equipo, para que tengan algo tangible al que referirse en el futuro. Eso también es bueno para anclar recuerdos.

Lo siento si ya lo has intentado ...

¿Has intentado hacer pre-lecciones para que las personas miren individualmente?

Haga videos o presentaciones breves que expliquen el contenido, cómo funciona el código o básicamente todo lo que desea enseñarles en un formato en el que necesitan verlo por su cuenta y aprender la información que intenta enseñarles. .

Luego, utiliza las sesiones basadas en el equipo para discutir temas relacionados con el contenido. Debe identificar claramente que las sesiones del equipo son solo para discutir y resolver problemas relacionados con el contenido.

Si proporciona las lecciones a las personas de forma individual, puede evitar ese otro problema social en el que un solo asunto puede convertirse en la voz del grupo como un colectivo y distraerse del propósito real de las lecciones.

Pruebe enseñándoles primero el diseño del código base, guíelos alrededor de la arquitectura, ANTES de comenzar a ver ejemplos específicos. De esa manera, podrían ver cómo los ejemplos de código que ves encajan en la imagen más grande. Piensa en cómo está estructurado tu programa de entrenamiento. E incluye la motivación empresarial detrás del diseño.

Pasé varios años entrenando a otros desarrolladores, y nunca ingresé en el código antes de mostrarles cómo encajaba el sistema. Luego, cuando los hice haciendo ejercicios de código en el marco, las preguntas estaban estructuradas y sobre el tema.