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

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

Te recomendaría que seas firme con él/ella y le digas algo en el sentido de:

La razón por la que repasamos las convenciones de nomenclatura es porque son muy importantes. Este código necesita ser mantenible en el futuro. Mucha gente por aquí ha trabajado duro para llegar a donde están, y es posible que no aprecien este tipo de bromas. Absténgase de usar este tipo de nombres en el futuro, ya que puede hacer que las personas cuestionen su profesionalismo.

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

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

1. Autonomía
2. Maestría
3. Objetivo

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

Arregla la tarea y los trabajadores te seguirán.

Algunos ejemplos:

1. Aquí está este proyecto, trabajen juntos y háganlo ____, háganme saber 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 las personas cumplan con la regla "ámalo, cámbialo o déjalo". En este caso, el pasante, que parece ser de la opinión de que la directriz es innecesaria, debería simplemente aceptarla de todos modos; o mantener la discusión al respecto; o dejar de hacer lo que hace. No poner en el equivalente a algunas manchas en el inodoro. No habría tenido ninguna objeción contra un nombre de método verdaderamente divertido y creativo. Si usted (el OP) encuentra el nombre del método simplemente divertido y no "malo" como yo, ignore esta respuesta, por favor.

Como antecedente, he supervisado a algunos pasantes muy inteligentes y (auto) motivados en el pasado, y nunca hubo dudas sobre si se comportarían profesionalmente o no. Llevar tonterías de nivel escolar a un lugar de trabajo como pasante está tan fuera de lo aceptable que sugeriría no perder el tiempo. Por los tuyos y sobre todo por el bien de ellos.

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

En primer lugar, olvídate de las convenciones de codificación. El problema no está relacionado con las computadoras o la programación.

• no mientas No se ande con rodeos, no se ría, porque realmente no es cosa de risa.
• No seas personal. No se trata de ti , el OP, ni de tu relación con ellos. Se trata pura y estrictamente de su comportamiento.
• Explicar las cosas como son. Absolutamente puede decirle al infractor que entiende cómo se le ocurrió la idea de hacer lo que hizo, y que no está personalmente enojado con él o lo que sea (evite las emociones), pero que está viendo la pasantía como una proyección de a quien tomar a bordo más tarde.

Si desea transmitir alguna emoción al respecto, manténgase alejado de la ira. Puedes mostrar una leve tristeza (y, francamente, eso sería exactamente lo que yo sentiría en realidad) y mostrarles que estabas bastante decepcionado.

Aún así, su desempeño durante la pasantía afectará sus posibilidades de ser contratado y situaciones como esta pueden jugar un papel más adelante.

¡Absolutamente! No te entretengas con "puede desempeñar un papel más tarde". Un comportamiento como este puede, debe y hará que sus posibilidades de recibir una oferta después de la pasantía sean cero. Puede decir eso de cualquier manera que normalmente le hable, simple y claramente.

Trate de encontrar la causa raíz. Si te enteras de que tampoco...

• ...están aquí en contra de su libre albedrío (tal vez sus padres, o su escuela o lo que sea, los obligaron a elegir una pasantía y casualmente eligieron su empresa)...
• ...no están interesados ​​en absoluto en el desarrollo de software de estilo "comercial"...

...entonces ofrecer cancelar la pasantía no sería lo peor que podrías hacer. El problema no es que pierdas tu tiempo (habías asignado mucho tiempo para supervisarlos en cualquier caso, en realidad no empeoraron las cosas para ti), el problema es que su tiempo está perdido.

¿O debería decirles algo similar para que estén más motivados para aprender algo?

Bromearía "todos los humanos pueden aprender, pero a ningún humano se le puede enseñar". Creo que le resultará muy difícil motivar a esa persona para que aprenda sobre la utilidad de las convenciones de codificación, ya que ya demostró que no tiene ningún interés en ellas. Puedes enseñar a aquellos que estén interesados ​​en lo que tienes que decir; pero si alguien es desinteresado, no hay nada que puedas hacer, realmente.

Si realmente quieres ayudar a esa persona a "ver la luz", entonces pídele que trate de seguirle el juego por su propio bien, tal vez aprenda a apreciar lo que puedes ofrecer, más adelante. Las pasantías 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 solo tienes que arreglar los problemas usando la autoridad. Llame a los pasantes a una reunión y exija saber por qué no se siguieron las convenciones de nomenclatura.

Expliqué las convenciones de nomenclatura a seguir en nuestra reunión anterior. Encontré varios casos en los que no se siguió la convención de nomenclatura. Por ejemplo, convertToMillilitersBecauseIAmUsingSuchCleanCode. ¿Podría explicar por qué se eligió este nombre?

Su "respuesta" es irrelevante, esto debería servir como una "primera advertencia" suficiente de que ir en contra de las instrucciones de su supervisor (que supongo que usted es) y hacer bromas a su costa no es aceptable en un entorno profesional. Eso incluso encaja bien con un objetivo de la pasantía, 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 pasantes serán contratados en la empresa en el futuro en función de su desempeño.

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

Tome un código de trabajo y haga algo para romperlo deliberadamente. Luego ejecútelo a través de un ofuscador que cambia todos los nombres de clases, variables y métodos a cosas como "a___1318798_" y "xy23_7a963"; o peor, nombres de variables con muchos caracteres de la letra O, la letra I, el número 0 y el número 1. Que sea su tarea documentar lo que está haciendo el código y corregirlo.

Esto curará las bromas.

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

Cuando encuentre tales tonterías durante las revisiones de su código, ríase, detenga la revisión del código y dígales que regresen una vez que hayan eliminado el humor.

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

Con suerte, está realizando un seguimiento de su rendimiento y puede notar con qué frecuencia sucede esto.

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

"Pasante, vi el nombre de su método de broma. Entiendo por qué lo hizo, pero no pensé que fuera tan gracioso, yo mismo. Así que se me ocurre preguntarle, ¿qué está haciendo aquí? te gustaría lograr?"

Si los pasantes dicen que solo está allí para jugar, entonces hable con la gerencia para finalizar su pasantía. Estás perdiendo tu tiempo.

Si dice que está allí 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 date cuenta de que no solo te estás tomando tu tiempo, también me estás tomando mi tiempo. La pasantía que has tenido proporcionado por la compañía es, en esencia, una especie de entrevista. Lo único que impide que sea una caridad absoluta de nuestra parte es la esperanza de encontrar buenos candidatos. Así que vale la pena mi tiempo, pero solo si se lo toma en serio".

"Si no puede tomarlo en serio y trabajar como si estuviera escribiendo un código de producción importante, ¿cómo podemos evaluarlo adecuadamente y decidir si le ofrecemos un trabajo? E incluso si no le ofrecemos un trabajo, si usted Si aún no te lo tomas en serio, ¿de qué otra forma adquirirás estas habilidades y podrás practicar bajo la valiosa dirección de alguien con más experiencia que tú?"

"Si yo fuera usted, haría todo lo posible para seguir el ejemplo de las personas que lo guían, quienes, de manera algo caritativa, están tomando tiempo no rentable de su trabajo para invertirlo en usted. Considere que se beneficiará de esta pasantía ya sea ¡te contratemos o no! Personalmente, te agradecería que te tomaras esto un poco más en serio. ¡Hazlo por ti mismo! Si no quieres hacerlo por ti mismo, hazlo por respeto, o simplemente por gratitud, por el momento. Me he apartado de mi trabajo productivo normal para invertir en ti y en tu futuro".

Probablemente sea apropiado abordar directamente el comportamiento en sí y por qué le estás dando tanta importancia. Podrías considerar algo como esto:

"Por lo que vale, 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 quiso decir de esa manera [incluso si no lo cree, dígalo], pero por favor, siga mis instrucciones en el futuro sin poner cosas sarcásticas en el código".

Dar el "fuera" del pasante diciendo "oh, sí, no quise faltarle el respeto" le permite salvar las apariencias y reparar la relación de la manera menos dolorosa posible. No hay necesidad de obtener una confesión de que lo dijo en forma irrespetuosa o de obtener una gran disculpa. El punto aquí no es dominar sino una pasantía exitosa.

Si después de todo esto, el comportamiento negativo continúa, puedes abordarlo más de frente. No hay ninguna razón por la que no pueda dar una meta de rendimiento a un pasante tal como lo haría con un empleado problemático, o usar cualquier otra estrategia que usaría con un empleado regular. Pero recuerde que los pasantes NO tienen experiencia en el mundo laboral y se les debe dar un descanso o dos mientras usted los acostumbra con cuidado, pero con firmeza, a los estándares del mundo laboral profesional.

Trabajé con algunos chicos recién salidos de la escuela. Hicieron este tipo de cosas no a propósito, sino porque sintieron que no tenía sentido ser demasiado pedantes. La legibilidad o reutilización del código simplemente no tenía sentido para ellos. Entonces, me molesté, pero no pude reprender a ninguno de ellos ya que yo no era su jefe.

Los programadores son generalmente un grupo inteligente y "porque yo lo digo" rara vez es una buena razón para implementar algo, incluso si es la mejor práctica de programación.

Revisaría el código, me aseguraría de decirles que el humor está fuera de lugar y que sus extrañas convenciones de nombres hacen perder bastante tiempo. Para la siguiente tarea los dividiría en dos: los graciosos de un lado, el resto del otro. Harían la misma tarea, pero el grupo divertido debería tardar mucho más porque no están siguiendo las mejores prácticas. Me aseguraría de que la tarea sea lo suficientemente compleja como para hacerles perder mucho tiempo si mantienen sus convenciones.

También puede asignar a un tipo divertido para depurar el código de otro tipo divertido. No creo functionThatDudeToldMetoDefineque llegue a la versión final con este nombre.

En cualquier caso, la única forma de aumentar tu autoridad es ponerlos en situaciones en las que se demuestren a sí mismos que lo que afirmas es cierto.

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

Su disposición a desperdiciar recursos de la empresa innecesariamente es una parte relevante de su evaluación de desempeño y puede conducir a una terminación prematura de su pasantía para gastar los recursos de la empresa solo en aquellos pasantes realmente interesados ​​en aprender cómo ser una parte valiosa, responsable y confiable de el lugar de trabajo a quien se le pueden confiar tareas e instrucciones.

Se lo diría a todos los becarios, mostrando algún código de ejemplo, que no mencionen a su autor, que no le dediquen más de 2 minutos y, si luego se arregla el código y no se repitan incidentes similares, que no lo vuelvan a mencionar.

Si no se escucha el disparo de advertencia, el siguiente paso es una conversación abierta solo con el interno en cuestión y posiblemente con un superior suyo (sin embargo, asegúrese de que esté en su bote). Luego, debe decidir si le debe a los otros pasantes 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 a pesar de que ahora es más largo.

Reprenderlos por bromear probablemente no hará que respeten más tu autoridad, así que me enfocaría en el tema como si fuera cualquier otra función mal nombrada. No necesariamente me haría 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 eligieron:

"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 esa manera, es una oportunidad de aprendizaje para ellos sobre lo que hace un buen nombre de función y no los confronta directamente. Como beneficio adicional, es posible que reconozcan el hecho de que solo estaban bromeando y sientan algo de vergüenza por hacerles perder el tiempo a todos.

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

Sería mejor realizar un tutorial de código en el que el desarrollador tenga que explicar su código a las personas con autoridad.

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

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

Obviamente, debe hacer que se detengan, pero simplemente decirles que no demuestren por qué.

Sé que la pauta de 80 caracteres por línea no es una regla estricta, 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 guía a partir de ahora, pero que tampoco les permitan cambiar los nombres de las variables que han elegido. Algo así como "has hecho tu cama, ahora túmbate en ella".

Tendrás la oportunidad de probar y machacar una nueva práctica en sus cabezas (suponiendo que no estén manteniendo las líneas cortas), los becarios que no entienden por qué los nombres largos de variables son malos están a punto de descubrirlo, y los becarios "inteligentes" pronto descubrirán que no están siendo tan inteligentes como pensaban.

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

Simplemente dígale al infractor (personalmente o por correo electrónico) que la pasantía no es un lugar apropiado para este tipo de bromas y que debe tomárselo en serio si quiere comenzar una carrera.

Pídales que arreglen el código o (si desea mostrar cierta autoridad) simplemente revierta sus cambios en el control de versiones.

Esto no tiene por qué ser "talla única".
Todos los tamaños se ajustan a algunos:

Cada uno de los enfoques propuestos puede funcionar muy bien y puede ser el mejor enfoque según las circunstancias. Aquí está mi respuesta a cada uno de los enfoques sobre los que se me preguntó:

¿Debo reaccionar por

• riéndose ("Sí, es divertido, pero por favor quítalo")

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

• solo pido educadamente que lo eliminen

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

• diciendo que no me gusta cuando alguien me hace perder el tiempo y que debería tomarse la revisión del código más en serio

Esta es una gran idea cuando: Desea comunicar molestia y mantener un enfoque autoritario.

(Me inclino a pensar que podría 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 deben terminar porque simplemente me hacen go [simulacro de grito] "podría ser una manera humorística de lograr eso).

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

Pero ¿Qué es lo mejor?
Su pregunta básica es: "¿Cómo debo reaccionar ante esto?"

Básicamente, esta pregunta se reduce a decir: "Necesito llegar a algún lugar. ¿Debo usar un monociclo, un saltador, una bicicleta o un autobús?"

Cualquiera de esos enfoques de transporte puede ser mejor. De manera similar, para responder a la pregunta de cómo debe 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 pasantes no es adecuado para los resultados de producción, las diferentes respuestas parecen favorecer diferentes enfoques. Como se señaló, es posible que no tengamos un único enfoque de "talla única" que funcione universalmente mejor para todos.

Estamos tratando con personas aquí, por lo que lo que funciona mejor en algunos escenarios puede no funcionar tan bien en otros escenarios. Uno de los factores clave eres tú. ¿Se puede ser severo sin quemar puentes? ¿Puedes hacerte amigo de ellos siendo alegre, pero asegurando suficiente cumplimiento e inspiración para obtener los resultados deseados? Lo que funciona mejor para mí podría funcionar terriblemente terrible para ti. En última instancia, debe tomar una decisión sobre cuál de esos enfoques tomar.

Enseñanza flexible: no se comprometa con un solo enfoque.

Simplemente elija el método con el que se sienta más cómodo. Asegúrate de no exagerar (humor malo/ofensivo, o crear un ambiente incómodamente 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 tomes una decisión que no funcione como esperabas. Siempre que no haya causado ningún problema importante, esto puede ser muy recuperable, si se maneja de manera positiva y rápida. Esa es una de las razones por las que no debe preocuparse demasiado por tratar de tomar la decisión más perfecta. Si las cosas no van bien, su situación puede salir bien. Las personas son diferentes, y el aprendizaje puede ser impredecible, y no tiene por qué avergonzarse de que un primer enfoque necesite modificaciones. Mientras se recupere rápidamente, esto puede no ser un problema.

La clave es hacer cambios tan pronto como comiences a encontrar resultados no deseados. Espere tener que adaptarse rápidamente. Cuando algún enfoque no funcione, prepárese para modificar rápidamente el enfoque, o incluso tirarlo por la ventana. Si lo que está haciendo no funciona, determine si es probable que esté al borde de un gran avance o si necesita probar algo diferente. (Obtener retroalimentación ayudará con esta determinación). Si necesita probar algo más, entonces hágalo. Siga haciendo eso hasta que obtenga resultados de trabajo.

Siempre que actúe rápidamente (antes de que los sentimientos a largo plazo, como la amargura, comiencen a afianzarse), las imperfecciones menores pueden pasarse por alto fácilmente como insignificantes en comparación con los resultados positivos que logra en general. (Solo asegúrese de que si las cosas van de manera imperfecta, los problemas sean menores. Los errores importantes pueden ser un poco más difíciles de olvidar. Por ejemplo, el intento de humor puede ser peligroso).

Por ejemplo, si descubre que comienzan a odiarlo, a temer el medio ambiente, etc., asegúrese de aclarar cualquier malentendido. Asegúrales que estás de su lado. Fomentar el comportamiento deseado. etc.

Hace dos años estaba en un puesto similar al de los becarios de su empresa. Puedo imaginar un escenario en el que habría hecho algo similar. Creo que algunos becarios tienen problemas con su autoridad; ser pedante y/o poco profesional. Esto se debe principalmente a la falta de respeto que tiene mi generación hacia los mayores y los que están en posiciones más altas. Probaría los siguientes métodos para resolver la situación.

• Gánate el respeto de los pasantes burlando al "líder", "alfa".

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

• Señale una falla en la función "convertToMillilitersBecauseIAmUsingSuchCleanCode" y sugiera un cambio de nombre a algo apropiado (/ degradante)

• No haga caso, ignore el nombre de la función; enfoca tu tiempo en las personas que quieren aprender.

Tomaría nota de los nombres de los pasantes no profesionales como medida de precaución.

Como profesional desde hace casi 30 años, diría que las respuestas mejor calificadas en su mayoría tienen razón.

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

Poner cosas tontas en los comentarios del código, o incluso nombrar 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 junior (que obtuvo 48 votos a favor).

Si hay un problema aquí, debería ser que hay problemas legítimos de legibilidad/mantenimiento con su código fuente en su entorno. No estoy diciendo que las mejores respuestas aquí sean incorrectas. no lo son Pero cuando ve este tipo de comportamiento de varios ingenieros junior, luego de limpiar los cuerpos, realmente debería investigar si puede haber una razón subyacente por la que sus canarios siguen muriendo .

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

¿Debo reaccionar por

• riéndose ("Sí, es divertido, pero por favor quítalo")
• solo pidiendo cortésmente que eliminen
• diciendo que no me gusta cuando alguien me hace perder el tiempo y que debería tomarse la revisión del código más en serio

¿Qué tal " Entender por qué hicieron esto? "

Cada vez que alguien hace algo que no esperas o deseas que haga, puedes reaccionar para que haga lo que quieres o puedes tratar de entender por qué hizo exactamente eso.

Puede ser útil entender por qué. Si son juguetones por naturaleza pero no pueden expresar sus frustraciones por algo, así es como alguien puede canalizarlas. Todos podemos estar de acuerdo en que esta no es una forma positiva de canalizarlo.

Un enfoque alternativo

Entonces, ¿cuál es una forma positiva de canalizar la frustración y el juego? He trabajado en empresas donde la gente a veces hacía proyectos el 10 % del tiempo, como programar un microcontrolador para tomar una selfie con una dslr. No solo obtuvieron rienda suelta para hacerlo, sino que se les dio la responsabilidad de convertirlo en un producto que se pueda enviar. Pasó de un hackathon de un día a ejemplos de código que ahora se publican en el sitio web de la empresa. Las personas pueden tomar ese ejemplo y convertirlo en un control remoto para cámaras de aguas profundas que se pueden encender con solo hacer clic en un botón.

Mi punto es que bromas como esta pueden ser una indicación de un potencial sin explotar. Si quieres becarios 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 ve el valor de sacudir las cosas, haga que estos bromistas creen algo útil con sus bromas. En última instancia, depende de usted. ¿Quiénes quieres que sean estos pasantes?

Parece que tiene un muy buen ejemplo para mostrarles por qué usar este tipo de convención de codificación es inapropiado, incluso para proyectos pequeños como este.

lo viste

Incluso si su proyecto no está siendo utilizado directamente por la empresa, está destinado a actuar como una evaluación de su habilidad y, en parte, como una experiencia de aprendizaje para estos pasantes que buscan abrirse camino en su empresa.

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

Comenzando por asumir buena fe, mi instinto me dice que los becarios hicieron esto porque realmente no ven ningún problema con nombres como convert. Apostaría una pequeña suma de dinero a que los nombres sarcásticos no provienen de un deseo de rebeldía sino de la frustración de no saber cómo encontrar un nombre mejor , solo un nombre más largo . Y eso es algo así como lo que les dijiste, ¿verdad? Corta mala, larga buena.

Si desea que estas personas mejoren, simplemente necesita discutir, en la reunión diaria, exactamente por qué convert es un nombre pobre y convertInchesToCentimeterses un nombre mejor. Si tiene un ejemplo de su experiencia de mala elección de nombres que causa problemas, eso les ayudará. Ese "por qué" les permitirá elegir buenos nombres a partir de ahora, ya sean esos buenos nombres largos o cortos.

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

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

• Vale la pena gastar mi tiempo con usted en este esfuerzo, cuando podría estar trabajando en aplicaciones "reales", así que también haga su mejor esfuerzo.
• Este ejercicio te prepara para trabajar en un proyecto real que es serio y en el que debes seguir pautas de estilo
• Este ejercicio nos permite decidir a cuál de ustedes, si alguno, extender las ofertas de empleo después de que finalice su pasantía.

Si bien no es exactamente incorrecto, creo que acusarlos de falta de respeto, etc. en este punto probablemente silenciará el comportamiento, pero tampoco los ayudará a comprender por qué necesitan mejores nombres o cómo encontrar mejores nombres. Si tomas este camino, es posible que los encuentres con nombres falsos más largos y evitando tu mirada de acero.

En primer lugar, no creo que esto sea tan malo. Ponen una broma en el código sobre un tema (convenciones de nombres) que probablemente no comprendan por completo. Poner algunas bromas internas en el código no es algo nuevo. Además, pueden considerar el código como una "hoja interna".

Tampoco estoy de acuerdo con la opinión de que te hacen perder el tiempo con esto. Si hacen una confirmación solo para cambiar el nombre de un método, entonces sí, están perdiendo el tiempo y el cambio debe rechazarse. Pero si necesitaban un método nuevo y elegían un nombre deficiente, el tiempo de revisión sería similar con cualquiera de los dos nombres. No sé si está revisando la confirmación previa o la confirmación posterior, pero cuando alguien quiere que se apruebe/fusione el código, lo que está haciendo en realidad va en contra de sí mismo, ya que simplemente está agregando viajes de ida y vuelta para que se acepte el código. .

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

Ahora, acercándonos a la pregunta real sobre qué hacer, recomiendo mencionar 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 llegaban nuevos a ese proyecto. Pídales que preparen un breve informe sobre las funciones que agregaron en esa semana y que lo justifiquen brevemente.

Idealmente, eso sería alrededor de una línea por función, por ejemplo.

convertGalToml: Convierte galones a mililitros. Camel case no se usó en la abreviatura de mililitros para evitar confusiones con megalitros.

Se espera que mientras revisan el código, puedan notar nuevos problemas o pensar en un nombre mejor, por ejemplo. renombrar convertGalTomla convertGal2ml.

Sospecho que tu bromista entenderá el punto y lo renombrará en silencio.

El punto es que los nombres de las funciones son documentación. Aunque es un público más técnico que por ej. el manual del usuario, deben sentirse cómodos justificando su elección frente a sus compañeros.

Si bien el comportamiento de los pasantes puede ser poco profesional, también es poco profesional que la gerencia no considere que podrían estar equivocados. Claramente convert, puede ser demasiado corto o ambiguo en muchos contextos, pero convertGallonsToMilliliterses demasiado largo para un nombre de identificador. En lugar de imponer requisitos de verbosidad de nombres arbitrarios en todos los ámbitos, debe desafiar a sus pasantes a justificar cuándo un nombre que eligen es realmente ambiguo (lo que no podrán hacer) y encontrar algo razonable que mejore la legibilidad del programa en lugar de obstaculizar eso.

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

No eres su manager, ni siquiera importa que los entrevistes o no. eres ingeniero como yo

Para que sepa qué hacer, hable con su gerente y luego sugiera una revisión del código. Luego aconséjeles que no escriban código como ese a través de un sistema como colaborador de código. Ni siquiera necesita enviarles un correo electrónico o interactuar con ellos o tomar estas cosas personalmente. Introducir un sistema de calificación basado en esa revisión de código. No intente controlarlos o ser su gerente, o intente administrar personas. Eso no es cosa tuya.

Hable con su gerente y conserve ese privilegio para rechazar o aprobar confirmaciones después de una revisión para usted mismo. Suponga que cada pasante tiene 10 puntos iniciales, y debe ganar 100 puntos a través de su calificación, y si realmente quiere unirse a su equipo, estará motivado para obtenerlo. Para no perder ningún punto.

Si yo fuera un pasante y estoy trabajando para usted y usted es solo un ingeniero senior, incluso yo odio si se encarga de la gestión de mi gente. NO es tu trabajo.

Me parece que has ido demasiado lejos y se ha salido de control. Aprende esa lección como ingeniero. Usted es un ingeniero, no su gerente para que las personas los administren.