¿Cómo hago para que la gente deje de andar en bicicleta (enfocándose en trivialidades)?

Se me ha encomendado la tarea de enseñar a otros equipos una nueva base de código, pero sigo teniendo problemas. Cada vez que voy a recorrer el código con las personas, no llegamos muy lejos antes de que todo el ejercicio se convierta en un ejercicio de eliminación de bicicletas (miembros de una organización que otorgan un peso desproporcionado a cuestiones triviales). Como no conocen la base de código, pero creen que necesitan ayudar a mejorarla, se centran en las cosas que pueden entender:

Why is that named that? _{(2 minutos para explicar por qué se llama así, más de 10 minutos debatiendo un nuevo nombre)}

Why is that an abstract base class rather than an interface? _{(2 minutos para explicar, más de 10 minutos para debatir los méritos relativos de esta decisión)}

...y así. Ahora, no me malinterpreten: los buenos nombres y el buen diseño consistente son importantes, pero nunca llegamos a discutir qué hace realmente el código o cómo está diseñado el sistema de manera significativa. He realizado algunas reuniones de arbitraje para sacar a la gente de estas tangentes, pero se han ido, distraídos por lo que el código será / debería ser cuando se arregle su trivialidad mascota, y se pierdan el panorama general.

Así que lo intentamos más tarde (o con una parte diferente de la base de código) y dado que la gente no tenía suficiente conocimiento para superar el efecto de cambio de bicicletas, se repite.

He intentado grupos más pequeños, grupos más grandes, código, pizarra, diagramas de visio, muros de texto gigantes, dejándolos simplemente discutirlo hasta la muerte, acortando los argumentos de inmediato ... algunos ayudan más que otros, pero nada funciona . Demonios, incluso intenté que otras personas de mi equipo lo explicaran porque pensé que podría ser que soy malo para explicar las cosas.

Entonces, ¿cómo educas a otros programadores lo suficiente como para que dejen de obsesionarse con las trivialidades y puedan contribuir significativamente al diseño?

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

Se le ha dado el trabajo incorrecto, o tal vez malinterpretó el trabajo que se le ha dado.

Al presentar a nivel de código, invita 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: desea que comprendan el sistema. Si la gente "lo hubiera hecho de manera diferente", está bien. Quizás de acuerdo. O no. Pero sigue adelante. Es como es ahora.

Cuando llegue al nivel de código, ya los habrá preparado con la terminología del sistema. Los nombres (supongo) tendrán sentido. Igual que el anterior: sin discusión extendida, preguntas para entender. Siga adelante.

Ahora establezca algunos problemas de clase para resolver. ¿Cómo podemos hacer una mejora X? Elija algo no trivial que "vaya con el flujo" del diseño del sistema y analice lo que cambiaría. Deberían estar obteniendo los fundamentos del sistema ahora. Elija otra mejora que pueda romper el sistema si se hace mal, y muestre cómo se puede hacer bien. Ese debería ser un momento Ah Ha para ellos. ¡Algunos incluso te pueden ganar!

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. Confiesa y comienza de nuevo. Asumimos que son personas inteligentes. Déles el desafío de pensar en el nivel superior. Y divida los grupos que ya existen seleccionando diferentes secciones transversales de equipos para las nuevas sesiones.

"Aparcarlos". Al comienzo de la lección, explique lo que debe discutir y explique claramente lo que se considera fuera del tema. Si le hacen una pregunta que es claramente OT, dígalo y continúe. Si vuelven a ello, escriba la pregunta en una pizarra (Esto es crítico) 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, p. Ej.

"... al analizar este problema, asegurémonos de no centrarnos en x, y y z. Asegurémonos también de que no estamos viendo detalles de implementación como a, b, co detalles triviales como j, k, l. Sé que seguramente habrá muchos detalles en el código y detalles que podrían abordarse, mejorarse o hacerse más estándar, pero primero intentemos ver qué está logrando en un nivel superior. "

Entonces, ¿cómo educas a otros programadores lo suficiente como para que dejen de obsesionarse con las trivialidades y puedan contribuir significativamente al diseño?

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

La clave de cualquier buena reunión es que todos sepan:

• por qué estás teniendo una reunión y
• lo que esperas sacar de eso
• cuánto debería durar

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

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

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

Persona nueva: "¿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?"

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

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

Usted: "Siento 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 pasar por eso una o dos veces, puede resumirlo en "Eso está fuera del alcance de esta reunión".

Tenga en cuenta que usted está no diciendo "Eso es tonto como para preocuparse por" o "No importa" o "Shut up" o "Eres demasiado nuevo como para tener de entrada." Simplemente está enfocando la reunión en lo que debe hacerse y el tiempo involucrado.

En ciertas organizaciones, nunca podrás lograr esto. Muchas organizaciones valoran las disputas políticas y el ascenso en la escala más que la capacidad intelectual, la diligencia y la lealtad. Y por qué no lo harían. Subir escaleras coloca a las personas en posiciones de poder, les permite mejorar sus vidas personales con ingresos más discrecionales y realmente nunca se vuelve obsoleto.

Compare esta disputa de poder con la resolución real de problemas, el pensamiento abstracto y la toma de decisiones sobre asuntos difíciles de los que pueden ser responsables de las consecuencias de más adelante, y muchos empleados pesan mucho en el lado de tratar de andar en bicicleta todo lo posible.

El único consejo que sugiero es que deje en claro, en el contexto de su organización, si es posible, que el destino personal de estos participantes depende de su comprensión, contribución y esfuerzo hacia el problema real que está tratando de resolver. Si esa es la arquitectura empresarial, expresada en esta base de código de código de error y todos sus fallos, eso es todo. Dejar claro a los que deben hacer aportes significativos sustancial acerca de que . No es otra aleatoriedad, que resulta ser una manía de alguien mayor u otro y les hará ganar buenos puntos brownie al estar de acuerdo con dicho alguien mayor.

Esto a menudo es difícil de hacer, ya que la persona mayor generalmente no comprende la tecnología que está funcionando, no está interesada y, desafortunadamente, controla los ingredientes crudos: el tiempo de los empleados; contratación y despido, política de salas de conferencias, promociones, etc., etc. en serio, etcétera hasta el enésimo.

Lo que llamas bikeshedding, yo llamaría convertir el flujo de pensamientos de alguien en el nuestro. Al discutir nombres, patrones, llegan a comprender el código en sus propios términos y no hay forma de evitarlo, es necesario.

Además, no hay necesidad de realizar un recorrido muy detallado de toda una base de código, ya que los detalles se olvidarán mucho antes de que empiecen a trabajar en él.

Basado en 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á, digamos 25 minutos (depende del LOC, por supuesto), para poder hacer un recorrido de 5-10 minutos del código a los demás. Tres minutos de preguntas y repita 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 imponer el tiempo, no fuera del tema y controlar la unidad se ha entendido lo suficiente. Serán actores de su aprendizaje y estarán más enfocados en explicar a los demás que en el motociclismo.

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 a lo que referirse en el futuro. Eso también es bueno para anclar recuerdos.

Lo siento si ya lo has intentado ...

¿Has intentado hacer lecciones previas que la gente revise individualmente?

Realice 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 necesiten verlo por sí mismos y aprender la información que está tratando de enseñarles.

Luego, utiliza las sesiones basadas en equipo para discutir temas relacionados con el contenido. Debe identificar claramente que las sesiones de equipo son para discutir y resolver problemas relacionados solo 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 colectivo y distraerse del propósito real de las lecciones.

Intente enseñarles primero el diseño de la base de código, guíelos por la arquitectura, ANTES de comenzar a buscar 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 incluya la motivación comercial detrás del diseño.

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