¿Cómo manejar el comportamiento poco profesional de los internos?

No creo que reírse de ello sea el enfoque adecuado. Necesitan aprender que ya no están en la escuela. Dicho esto, tampoco creo que debas llevarlo demasiado lejos en el otro sentido.

Yo te recomendaría que seas firme con él/ella y le digas algo al efecto de:

La razón por la que pasamos por encima de las convenciones de nombres es porque son muy importantes. Este código necesita ser mantenible en el futuro. Mucha gente de por aquí ha trabajado duro para llegar a donde están, y puede que no aprecien este tipo de bromas. Por favor, absténgase de usar este tipo de nombres en el futuro ya que puede causar que la gente cuestione su profesionalidad.

En primer lugar, esto parece una broma que fue puesta en código que ellos saben muy bien que no se usará para nada ni se leerá nunca más. Creo que estás leyendo demasiado en este incidente. Lo importante es que les dijiste sobre la convención de nombres y no te ignoraron, ellos usaron nombres más largos y descriptivos (aunque sarcásticamente).

Después de ver este video puedo ver que los trabajadores desean 3 cosas:

1. Autonomía
2. Dominio
3. Propósito

Lo que les está pidiendo que hagan no es autónomo, probablemente es de dificultad trivial para algunos de ellos, y no sirve para nada a sus ojos.

Arregle la asignación, y los trabajadores seguirán.

Algunos ejemplos:

1. Aquí está este proyecto, trabajen juntos y háganlo por _________, avísenme si se atascan.

2. Sé que esto no parece importante, pero para evaluar tus habilidades y asignarte un trabajo que creemos que te ayudará a crecer necesitamos que termines esta tarea.

TL;DR : Me opongo al nombre del método porque (¡en mi opinión!) expresa desdén por el jefe y/o las “reglas” (aquí: pautas de estilo). En el lugar de trabajo, espero que la gente se atenga a la regla “ámalo, cámbialo o déjalo”. En este caso, el pasante, que parece ser de la opinión de que la pauta es innecesaria, debería aceptarla de todos modos; o mantener la discusión sobre ella; o dejar de hacer lo que hace. No poner el equivalente de alguna mancha en el inodoro. No habría tenido ninguna objeción en absoluto contra un nombre de método realmente divertido y creativo. Si usted (el OP) encuentra el nombre del método simplemente divertido y no “malo” como yo, entonces ignore esta respuesta por favor._

Como antecedentes, he supervisado a algunos internos altamente inteligentes y (auto)motivados en el pasado, y ni una sola vez hubo ninguna pregunta de si se comportarían profesionalmente o no. Traer la estupidez de la escuela a un lugar de trabajo como un interno está tan fuera de lo aceptable, que sugeriría no hacer tonterías. Por su propio bien y especialmente por el de ellos.

Me gustaría saber cómo manejar tal situación apropiadamente.

Primero que nada, olvídese de las convenciones de codificación. El tema no está relacionado con las computadoras o la programación.

• No mientas. No te preocupes por las palabras, no te rías, porque realmente no es un asunto de risa.
• No te pongas personal. No se trata de la OP, ni de tu relación con ellos. Es pura y estrictamente sobre su comportamiento.
• Explica las cosas como son. Puedes decirle al infractor que entiendes cómo tuvo la idea de hacer lo que hizo, y que no estás personalmente enfadado con él o lo que sea (mantén las emociones fuera), sino que estás viendo las prácticas como una proyección de a quién tomar a bordo más tarde.

Si deseas transmitir alguna emoción sobre ello, mantente alejado de la ira. Puede mostrar una leve tristeza (y francamente, eso sería exactamente lo que yo sentiría) y mostrarles que está bastante decepcionado.

Aún así, su rendimiento durante las prácticas afectará a sus posibilidades de ser contratado y situaciones como esta pueden jugar un papel más tarde.

¡Absolutamente! No te andes con rodeos con el “puede jugar un papel más tarde”. Un comportamiento como este puede, debe y hará que su oportunidad de recibir una oferta después de la pasantía sea cero. Puedes decirlo de la forma en que normalmente les hablas, clara y llanamente.

Intenta encontrar la causa de fondo. Si descubres que…

• …están aquí contra su voluntad (tal vez sus padres, o su escuela o lo que sea, les hicieron elegir unas prácticas y casualmente eligieron tu empresa)…
• …no están interesados en el desarrollo de software de estilo “empresarial” en absoluto…

…entonces ofrecerles abortar las prácticas no sería lo peor que podrías hacer. El problema no es que su tiempo se pierda (en cualquier caso, les habías asignado mucho tiempo para supervisarlos, no te lo hicieron peor), el problema es que su tiempo se pierde.

¿O debería decirles algo en este sentido para que se motiven más para aprender realmente algo?

yo diría “todo humano puede aprender, pero ningún humano puede ser enseñado”. Creo que encontrarás muy difícil motivar a esa persona para que aprenda sobre la utilidad de las convenciones de codificación, ya que ya han demostrado que tienen cero interés en ellas. Puedes enseñar a aquellos que están interesados en lo que tienes que decir; pero si alguien está desinteresado, no hay nada que puedas hacer, en realidad.

Si realmente quieres ayudar a esa persona a “ver la luz”, entonces pídele que trate de seguirle la corriente por su propio bien, tal vez aprenda a apreciar lo que puedes ofrecer, más tarde. Las prácticas son un intercambio de cualquier servicio limitado que puedan ofrecer, contra la experiencia de trabajar en un lugar de trabajo real. Si no están interesados en asimilar la experiencia, entonces realmente no tiene sentido. Presumiblemente, su empresa no depende de tener su “mano de obra” para algún proyecto real.

Todos odiamos hacerlo, pero a veces hay que arreglar los problemas usando la autoridad. Llama a los internos a una reunión, y exige saber por qué no se siguieron las convenciones de nomenclatura.

Ya expliqué las convenciones de nomenclatura a seguir en nuestra reunión anterior. Me encontré con un número de casos en los que la convención de nombres no fue seguida. Por ejemplo, convertToMillilitersBecauseIAmUsingSuchCleanCode. ¿Podría explicar por qué se eligió este nombre?

Su “respuesta” es irrelevante, esto debería servir como suficiente “primera advertencia” de que ir en contra de las instrucciones de su supervisor (que presumo que usted es) y hacer bromas a su costa no es aceptable en un ambiente profesional. Eso incluso encaja bien con un objetivo de las prácticas, que es mostrar a los estudiantes cómo trabajar en un entorno profesional.

Si continúan con su comportamiento infantil, entonces, bueno, creo que has llegado a la conclusión de esto:

Algunos de los internos serán contratados en la empresa en el futuro en función de su rendimiento.

Oh, un montón de idiotas, ¿eh?

Coge algún código de trabajo y haz algo para romperlo deliberadamente. Luego pásalo por un ofuscador que cambie todos los nombres de clases, variables y métodos a cosas como “a___1318798_” y “xy23_7a963”; o peor aún, nombres de variables con muchos caracteres de letra O, letra I, número 0 y número 1 en ellas. Hagan su tarea de documentar lo que el código está haciendo, y arréglenlo.

Esto curará esa broma.

Sé que probablemente no sea gran cosa, pero es la primera vez que ayudo a los internos y me gustaría saber cómo manejar esta situación adecuadamente. Aún así, su desempeño durante la pasantía afectará sus posibilidades de ser contratados y situaciones como esta pueden jugar un papel más adelante. O debería decirles algo en este sentido para motivarlos a aprender algo?

Cuando se encuentren con tal tontería durante sus revisiones de códigos, ríanse, detengan la revisión de códigos y díganles que vuelvan una vez que hayan eliminado el humor.

Asumo que no son estúpidos, y ya saben que el nombre demasiado largo es inapropiado, incluso si se ríen de él. Si no, explique por qué una vez.

Con suerte, usted está llevando la cuenta de su desempeño y puede anotar con qué frecuencia sucede esto.

Tendría una charla de corazón a corazón con cada uno de ellos, en privado, en un tono franco y serio pero no severo, algo así:

“Interno, vi tu nombre de método de broma. Entiendo por qué lo hiciste, pero no me pareció tan gracioso. Así que se me ocurre preguntarte, ¿qué estás aquí para hacer? ¿Qué te gustaría lograr?”

Si el interno dice que sólo está ahí para fastidiar, entonces habla con la dirección para terminar su internado. Estás perdiendo el tiempo.

Si dice que está ahí para aprender, entonces di algo como esto:

“Me doy cuenta de que puede ser difícil tomar en serio algo que sabes que no se usará en la producción. Pero, por favor, date cuenta de que no sólo te estás tomando tu tiempo, sino también el mío. Las prácticas que te ha proporcionado la empresa son, en esencia, una especie de entrevista. La única cosa que impide que sea una verdadera caridad por nuestra parte es la esperanza de encontrar buenos candidatos. Así que merece la pena mi tiempo, pero sólo si te lo tomas en serio.”

“Si no te lo tomas en serio y trabajas como si estuvieras escribiendo un importante código de producción, ¿cómo podemos evaluarte adecuadamente y decidir si te ofrecemos un trabajo? Y aunque no te ofrezcamos un trabajo, si todavía no te lo tomas en serio, ¿cómo vas a adquirir estas habilidades y ser capaz de practicar bajo la valiosa dirección de alguien con más experiencia que tú?

"Si yo fuera tú, haría todo lo posible por seguir el ejemplo de la gente que te guía, que, de alguna manera caritativa, se toma un tiempo no rentable de su trabajo para invertir en ti. ¡Considere que se beneficiará de estas prácticas tanto si le contratamos como si no! Personalmente apreciaría que se tomara esto un poco más en serio. ¡Hazlo por ti mismo! Si no quieres hacerlo por ti mismo, hazlo por respeto, o sólo por gratitud, por el tiempo que he quitado de mi trabajo productivo normal para invertir en ti y en tu futuro.”

Probablemente sea apropiado abordar de alguna manera directamente el comportamiento en sí, y por qué estás haciendo un poco de un gran problema de ello. Podrías considerar algo como esto:

“Por si sirve de algo, este tipo de acción se considera una falta de respeto, o incluso una burla, en el mundo corporativo. Estoy seguro de que no lo dijiste en ese sentido [aunque no lo creas, dilo], pero por favor sigue mis instrucciones en el futuro sin poner cosas sarcásticas en el código”

Dar el “fuera” del interno diciendo “oh, sí, no quise faltarle el respeto” le permite salvar la cara y reparar la relación de la manera más indolora posible. No hay necesidad de sacar una confesión de que lo hizo sin respeto o de obtener una gran disculpa. El punto aquí no es el poder, sino el éxito de las prácticas.

Si después de todo esto, el comportamiento negativo continúa, puedes abordarlo más de frente. No hay razón por la que no puedas darle un objetivo de rendimiento a un interno como lo harías con un empleado problemático, o usar cualquier otra estrategia que usarías con un empleado normal. Pero recuerde que los internos NO tienen experiencia en el mundo del trabajo y se les debe dar un descanso o dos mientras usted los acostumbra suave, pero firmemente, a los estándares del mundo laboral profesional.

Los internos en cuestión están desperdiciando su tiempo y paciencia. Su tiempo y paciencia son recursos caros y limitados para la empresa y los internos que se benefician de la inversión de la empresa en ellos, una inversión que está limitada por los recursos de la empresa.

Su voluntad de desperdiciar innecesariamente los recursos de la empresa es una parte relevante de su evaluación de desempeño y puede llevar a una finalización prematura de su pasantía para gastar los recursos de la empresa sólo en aquellos internos realmente interesados en aprender a ser una parte valiosa, responsable y confiable del lugar de trabajo a quienes se les puede confiar tanto tareas como instrucciones.

Yo les diría esto a todos los internos, mostrándoles algún código de ejemplo, no mencionar su autor, no gastar más de 2 minutos en él y, si el código se arregla posteriormente y no se repiten incidentes similares, no volver a mencionarlo.

Si el tiro de advertencia no se hace caso, el siguiente paso es una charla abierta sólo con el interno en cuestión y posiblemente con un superior suyo (sin embargo, asegúrese de que esté en su barco). Luego tienes que decidir si le debes a los otros internos eliminar al que está saboteando sus posibilidades de una pasantía exitosa.

Parece que hay dos problemas principales aquí: 1) Están siendo irreverentes y 2) El nombre de la función todavía apesta aunque ahora es más largo.

Reprenderlos por bromear no va a hacer que respeten más su autoridad, así que me centraría en el tema como si fuera cualquier otra función mal nombrada. No me haría necesariamente el tonto y fingiría que no me doy cuenta de que es una broma, pero les preguntaría por qué eligieron el nombre que hicieron:

“Parece que hay algunas palabras superfluas en el nombre de esta función que no ayudan a explicar lo que hace la función”.

De esta manera, es una oportunidad de aprendizaje para ellos sobre lo que hace que un buen nombre de función y no los confronta directamente. Como ventaja añadida, pueden confesar el hecho de que sólo estaban jugando y pueden sentir algo de vergüenza por hacer perder el tiempo a todo el mundo.

Si tienes que recordarle a la gente que estás a cargo, entonces nunca lo estuviste.

Sería mejor llevar a cabo un recorrido por el código donde el desarrollador tiene que explicar su código a las autoridades.

1. Esto inculca la responsabilidad personal por el resultado del proyecto
2. Proporciona una retroalimentación profesional inmediata
3. 3. Da al desarrollador un sentido de urgencia para completar el proyecto

Utiliza su liderazgo como parte del equipo para mantener los estándares de su organización. Luego, ayude a los empleados más jóvenes a cumplir con esos estándares y evite la vergüenza de presentar un trabajo por debajo de los estándares.

Sólo dile al infractor (personalmente o por correo electrónico) que las prácticas no son un lugar apropiado para este tipo de bromas y que tienen que tomarse en serio si quieren empezar una carrera.

Pídeles que arreglen el código, o (si quieres mostrar algo de autoridad) simplemente anula sus cambios en el control de versiones.

Obviamente, tienes que hacer que se detengan, pero simplemente diciéndoles que lo hagan podría no demostrar por qué.

Sé que la pauta de 80 caracteres por línea no es una regla rígida, de ninguna manera, pero tratar de cumplirla es una buena práctica, por lo que tener un nombre de variable de 48 caracteres es bastante tonto.

Sugeriría decirles que traten de seguir esta pauta de ahora en adelante, pero tampoco les permita cambiar los nombres de las variables que han elegido. Una especie de “has hecho tu cama, ahora acuéstate en ella”.

Podrás intentar martillar una nueva práctica en sus cabezas (asumiendo que no estén ya manteniendo líneas cortas), los internos que no entienden por qué los nombres largos de variables son malos están a punto de averiguarlo, y los internos “inteligentes” pronto descubrirán que no están siendo tan inteligentes como pensaban.

Es obvio para los codificadores más experimentados por qué convertToMillilitersBecauseIAmUsingSuchCleanCode es particularmente malo, pero en lugar de decirles “eso es malo”, oblíguelos a averiguar por qué. Apuesto a que encontrarán muchos menos nombres verbosos, y con suerte, menos intentos futuros de ser sarcásticos también.

Esto no tiene que ser “Una talla para todos”. Todas las tallas encajan algunas:

Cada uno de los enfoques propuestos puede funcionar muy bien, y puede ser el mejor enfoque dependiendo de la circunstancia. Aquí está mi respuesta a cada uno de los enfoques preguntados sobre:

¿Debería reaccionar por

• reírse de ello (“Sí, es divertido pero por favor quítelo”)

Esta es una gran idea cuando: Tienes una excelente relación con estos compañeros de trabajo, que se han hecho buenos amigos con

• pidiendo amablemente que lo quite

Esta es una gran idea cuando: Quieres ser directo para que no haya malentendidos

• diciendo que no me gusta cuando alguien pierde mi tiempo y que deberían tomarse la revisión del código más seriamente

Esta es una gran idea cuando: Desea comunicar la molestia, y se apega a un enfoque autoritario.

(Me inclino a pensar que podría ser capaz de combinar todos esos enfoques en una forma no ofensiva, educada y divertida que comunique que hay un poco de molestia real. “Este tipo de cosas debe parar porque me hace ir [simulacro de escaramuza]” podría ser una forma humorística de lograrlo)

Personalmente, me gusta el método amistoso. Soy un creyente en esa forma de hacer las cosas. Sin embargo, admitiré fácilmente que hay veces en las que tales enfoques son menos efectivos.

¿Pero qué es lo mejor? Tu pregunta básica es: “¿Cómo debo reaccionar a esto?”

Básicamente, lo que esta pregunta se reduce a decir: “Necesito llegar a algún lugar. ¿Debería usar un monociclo, un pogostick, una bicicleta o un autobús?”

Cualquiera de esos medios de transporte puede ser el mejor. Del mismo modo, para responder a la pregunta de cómo debería reaccionar: Su mejor reacción podría no ser mi mejor reacción.

Esta es una razón clave por la que, aunque las diferentes respuestas parecen estar de acuerdo en que el comportamiento de los internos no es adecuado para los resultados de producción, las diferentes respuestas parecen favorecer los diferentes enfoques. Como se ha señalado, puede que no tengamos un único enfoque de “un tamaño para todos” que funcione universalmente mejor para todos.

Estamos tratando con gente aquí, así que lo que funciona mejor en algunos escenarios puede no funcionar tan bien en otros. Uno de los factores clave es usted. ¿Puedes ser severo sin quemar los puentes? ¿Puedes hacerte amigo de ellos siendo despreocupado, pero asegurando suficiente conformidad e inspiración para obtener los resultados deseados? Lo que funciona mejor para mí puede funcionar atrozmente mal para usted. En última instancia, usted necesita hacer una llamada de juicio sobre cuál de esos enfoques tomar.

Enseñanza flexible: No se comprometa a un solo enfoque.

Sólo elija el método con el que se sienta más cómodo. Asegúrese de no exagerar (humor malo/ofensivo, o crear un ambiente incómodo y amenazante en un esfuerzo por ser estricto).

No importa cuál de sus excelentes sugerencias decida seguir adelante, vigile de cerca los resultados.

Es muy posible que haga un juicio que no funcione como se espera. Mientras no haya causado ningún problema importante, esto puede ser muy recuperable, si se maneja de manera positiva y rápida. Esa es una razón por la que no deberías preocuparte demasiado por tratar de tomar la decisión más perfecta. Si las cosas no van bien, tu situación puede salir bien. Las personas son diferentes, y el aprendizaje puede ser impredecible, y no tiene por qué ser una vergüenza que un primer acercamiento necesite ser modificado. Siempre y cuando te recuperes rápidamente, esto puede ser un no problema.

La clave es hacer cambios tan pronto como empieces a encontrar resultados indeseables. Espere que necesite adaptarse rápidamente. Cuando algún enfoque no funcione, esté muy preparado para modificarlo rápidamente, o incluso tirarlo por completo por la ventana. Si lo que estás haciendo no está funcionando, determina si es probable que estés al borde de un gran avance, o si necesitas probar algo diferente. (Obtener retroalimentación ayudará a esta determinación.) Si necesitas probar algo más, entonces hazlo. Sigue haciéndolo hasta que obtengas resultados de trabajo.

Mientras actúes rápidamente (antes de que sentimientos a largo plazo como la amargura empiecen a arraigar), las imperfecciones menores pueden fácilmente ser dejadas de lado como insignificantes en comparación con los resultados positivos que obtienes en general. (Sólo asegúrate de que si las cosas van imperfectas, los problemas son menores. Las grandes meteduras de pata pueden ser un poco más difíciles de olvidar. Por ejemplo, el intento de humor puede ser peligroso).

Por ejemplo, si descubres que empiezan a odiarte, a temer al medio ambiente, etc., asegúrate de aclarar cualquier malentendido. Asegúrales que estás de su lado. Fomente el comportamiento deseado, etc.

Hace dos años estaba en una posición similar a la de los internos de su empresa. Puedo imaginarme un escenario en el que hubiera hecho algo similar. Creo que algunos internos tienen un problema con tu autoridad, siendo pedantes o poco profesionales. Esto se debe principalmente a la falta de respeto de mi generación hacia los mayores y los que están en posiciones más altas. Intentaría los siguientes métodos para resolver la situación.

• Ganarse el respeto de los internos burlándose del “líder”, “alfa”.

• Usar el nombre de la función pedante como una lección para todos, longitud óptima del nombre de la función: zona de Goldilock.

• Señale una falla en la función “convertir a mililitros por usar un código tan limpio” y sugiera un renombre a algo apropiado(/demandante)

• No haga caso, ignore el nombre de la función; concentre su tiempo en los individuos que quieren aprender.

Yo anotaría los nombres de los internos no profesionales como precaución.

¿Debería reaccionar por

• riéndome de ello (“Sí, es divertido pero por favor, quítalo”)
• pidiendo educadamente que lo quite
• diciendo que no me gusta cuando alguien me hace perder el tiempo y que deberían tomarse la revisión del código más en serio

¿Qué tal “ *Entender por qué hicieron esto? *”

Cuando alguien hace algo que no esperas o deseas que haga, puedes reaccionar para que haga lo que quieres o puedes intentar entender por qué hizo exactamente eso.

Podría ser útil entender por qué. Si son juguetones por naturaleza pero no consiguen airear sus frustraciones sobre algo, así es como alguien puede canalizarlo. Todos podemos estar de acuerdo en que esta no es una forma positiva de canalizarla.

Un enfoque alternativo

Entonces, ¿qué es una forma positiva de canalizar la frustración y lo juguetón? He trabajado en compañías donde la gente a veces hacía proyectos el 10% del tiempo, como programar un microcontrolador para tomar un selfie con un dslr. No sólo obtuvieron rienda suelta para hacerlo, sino que se les dio la responsabilidad de convertirlo en un producto transportable. Pasó de ser un hackathon de un día a ejemplos de código que ahora se publican en el sitio web de la compañía. La gente puede tomar ese ejemplo y convertirlo en un control remoto para cámaras de mar profundo que pueden ser encendidas con el clic de un botón.

Mi punto es que bromas como esta pueden ser indicación de un potencial sin explotar. Si quieres internos que se ajusten al estándar que tienes en tu empresa, este potencial no es para ti y en ese caso, considera dejarlos ir. Sin embargo, si ves el valor de agitar las cosas, haz que estos bromistas creen algo útil con sus bromas. En última instancia, depende de ti. ¿Quién quieres que sean estos internos?

Como profesional desde hace casi 30 años, diría que las respuestas de alta calificación en su mayoría son correctas.

Sin embargo, como profesional desarrollador de software desde hace casi 30 años, diré que las pautas de codificación son casi siempre sobre-prescriptivas. Peor aún, a menudo esto es aprovechado por personas más preocupadas por su autoría que por producir código legible. Este tipo de comportamiento pasivo-agresivo de los ingenieros junior es exactamente lo que típicamente se ve cuando eso sucede.

Poner cosas tontas en los comentarios del código, o incluso en los nombres de los identificadores, es realmente una tradición consagrada entre los desarrolladores de software. Aquí hay un ejemplo de nombres de protesta inducidos por estándares de mis propios días de juventud (que obtuvieron 48 votos a favor).

Si hay un problema aquí, debería ser que hay problemas de legibilidad/mantenimiento legítimos con su código fuente en su entorno. No estoy diciendo que las respuestas principales aquí sean erróneas. No lo están. Pero cuando ves este tipo de comportamiento de múltiples ingenieros junior, entonces después de limpiar los cuerpos deberías realmente mirar si podría haber una razón subyacente para que tus canarios sigan muriendo.

El objetivo final debe ser la calidad del código. Las pautas de codificación deberían ser sólo su herramienta para ayudarles a llegar allí, construida por desarrolladores para desarrolladores, no algún tipo de programa autoritario para escribir programas.

Suena como si tuvieras un muy buen ejemplo para mostrarles por qué el uso de este tipo de convención de codificación es inapropiado, incluso para proyectos pequeños como este.

**Lo has visto.

Incluso si su proyecto no está siendo usado directamente por la compañía, está destinado a actuar como una evaluación de su habilidad y, en parte, como una experiencia de aprendizaje para estos internos que buscan abrirse camino en tu compañía.

Yo no sería demasiado duro con ellos - después de todo, esto _es sólo una prueba para ellos - pero definitivamente señalaría que, en el futuro, tales prácticas de codificación podrían meterlos en problemas, especialmente si su próximo jefe no es tan paciente con ellos como tú.

En primer lugar, no creo que esto sea tan malo. Pusieron un chiste en el código sobre un tema (convenciones de nombres) que probablemente no entienden completamente. Colocar algunos chistes internos en el código no es algo nuevo. Además, pueden considerar el código como una “hoja interna”.

También estoy en desacuerdo con la opinión de que te hacen perder el tiempo con esto. Si hacen una confirmación sólo para renombrar un método, entonces sí, están perdiendo tu tiempo, y el cambio debería ser rechazado. Pero si necesitaran un nuevo método y eligieran un nombre pobre, el tiempo de revisión sería similar con cualquiera de los dos nombres. No sé si está revisando el pre-compromiso o el post-compromiso, pero cuando alguien quiere que se apruebe/fusione el código, lo que está haciendo es en realidad trabajar en contra de sí mismo, ya que simplemente está añadiendo viajes de ida y vuelta para conseguir que se acepte el código.

También es trivial para usted calificar negativamente con nombres equivocados, sin mirar realmente lo que hace el código. El tema es que te sientes molesto con esos nombres.

Ahora, clavando la pregunta real sobre qué hacer, recomiendo sacar a relucir que tuvieron algunos problemas con las convenciones de nombres y pedirles que revisen el trabajo de la semana pasada para ver si han estado usando nombres propios y pensar si lo entenderían fácilmente en unos años / si fueran nuevos en ese proyecto. Pídales que preparen un breve informe sobre las funciones que añadieron en esa semana y que lo justifiquen en breve.

Lo ideal sería que fuera una línea por función, por ejemplo,

convertGalToml: Convierte galones en mililitros. No se usó la caja de camello en la abreviatura de mililitros para evitar ser confundido con megalitros.

Se espera que al revisar el código, puedan notar nuevas cuestiones o pensar en un nombre mejor, por ejemplo, cambiar el nombre de convertGalToml a convertGal2ml.

Sospecho que su bromista obtendrá el punto y silenciosamente lo renombrará.

El punto es que los nombres de las funciones son documentación. Aunque es una audiencia más técnica que, por ejemplo, el manual de usuario, deberían sentirse cómodos justificando su elección frente a sus compañeros.

Empezando por asumir la buena fe, mi instinto me dice que los internos lo hicieron porque no ven ningún problema con nombres como convert. Apostaría una pequeña suma de dinero a que los nombres sarcásticos no vienen de un deseo de ser rebeldes sino de la frustración de que no saben cómo llegar a un nombre mejor, sólo un nombre más largo. Y ese tipo de sorta es lo que les dijiste, ¿verdad? Corto malo, largo bueno.

Si quieres que estos individuos mejoren, sólo tienes que discutir, en la reunión diaria, exactamente por qué convert es un nombre pobre y convertInchesToCentimeters es un nombre mejor. Si tienes un ejemplo de tu experiencia en la elección de un mal nombre que causa problemas, eso les ayudará. Ese “por qué” les permitirá elegir buenos nombres de ahora en adelante, ya sea que esos buenos nombres sean largos o cortos.

También hágales saber que está bien pedirle a usted o a sus compañeros ayuda o consultarles dentro de lo razonable, que esto no es una prueba en la que todos tienen que trabajar solos, esto es una colaboración. (¡Espero que esto sea cierto!) Tal vez eso les permita hacer preguntas y hablar entre ellos, y resolver las frustraciones pronto, en lugar de esperar a que cosas pasivo-agresivas como esta aparezcan en la revisión del código.

Sólo si tal comportamiento continúa, encontraría necesario explicar, sí, esta no es una aplicación real, pero este ejercicio y las pautas de estilo deben ser tomadas en serio por múltiples razones:

• Vale la pena mi tiempo para dedicarles este esfuerzo, cuando podría estar trabajando en aplicaciones “reales”, así que por favor denle también su mejor esfuerzo
• Este ejercicio los prepara para trabajar en un proyecto real que es serio y en el que deben seguir las pautas de estilo
• Este ejercicio nos permite decidir cuál de ustedes, si es que hay alguno, extenderá las ofertas de empleo hasta después de que concluyan sus prácticas

Aunque no es exactamente incorrecto, creo que acusarlos de falta de respeto, etc. en este punto probablemente silenciará el comportamiento, pero también no les ayudará a entender por qué necesitan mejores nombres o cómo se les ocurren mejores nombres. Si toman este camino, podrían encontrar que sólo se les ocurren nombres malos más largos y evitar su mirada de acero.

No eres su manager, ni siquiera importa si los entrevistas o no. Eres un ingeniero como yo,

Así que ya sabes qué hacer, habla con tu gerente y luego sugiere una revisión del código. Luego aconséjales que no escriban código así a través de un sistema como el de un colaborador de código. Ni siquiera necesitas enviarles un correo electrónico o interactuar con ellos o tomarte estas cosas personalmente. Introduce un sistema de clasificación basado en esa revisión de código. No trates de controlarlos o ser su manager, o tratar de dirigir a la gente. Eso no es asunto tuyo.

Habla con tu gerente y mantén ese privilegio de rechazar o aprobar los compromisos después de una revisión para ti mismo. Supongamos que cada interno tiene un inicial de 10 puntos, y que debe ganar 100 puntos a través de tu calificación, y si realmente quieren unirse a tu equipo se sentirán motivados para conseguirlo. No perderás ningún punto.

Si yo fuera un interno y trabajara bajo tu mando y tú sólo fueras un ingeniero superior, incluso odiaría que hicieras mi gestión de personal. NO es tu trabajo.

Me parece que has ido demasiado lejos y se ha salido de control. Aprende esa lección como ingeniero. Eres un ingeniero, no su manager para que la gente los maneje.

Aunque el comportamiento de los internos puede ser poco profesional, también es poco profesional que la dirección no considere que pueden estar equivocados. Claramente convert puede ser demasiado corto de ambiguo en muchos contextos, pero convertGallonsToMilliliters es demasiado largo para un nombre identificador. En lugar de imponer requisitos arbitrarios de verbosidad en los nombres en general, debería desafiar a sus internos a justificar cuando un nombre que eligen es realmente ambiguo (lo cual no podrán hacer) y proponer algo razonable que mejore la legibilidad del programa en lugar de obstaculizarlo.

Esto realmente me parece un caso del patrón común de “¿por qué no me respetan mis subordinados?” siendo realmente una cuestión de “¿qué pasa con mi propia actitud que hace que la gente no respete mi posición?