¿Cómo decirle a su jefe que su estilo de programación es realmente malo? [duplicar]

Pídale que le explique su código

Dígale que nunca ha visto a X programado de esa manera, y pregúntele por qué lo codifica de esa manera. Muéstrale la forma en que lo codificas y explica por qué lo haces de esa manera (mejores prácticas, mejor rendimiento, menos posibilidades de errores, más fácil de leer / mantener para otros programadores, etc.).

Asegúrese de preparar todos sus argumentos por adelantado y concéntrese en por qué su método es mejor en lugar de por qué su método es peor. Luego, ve si aún apoya su método sobre el tuyo.

Si está abierto a la mejora, es probable que cambie su forma de codificación. Si aún prefiere usar su estilo de codificación sobre el tuyo, es probable que no cambies su opinión.

Promueva el uso del análisis estático automatizado y las herramientas de verificación de estilo, como los linters y los buscadores de errores (en cualquier idioma que use). Si todos los miembros de la compañía comienzan a usarlos (por ejemplo, tienen el mandato antes de los registros), no se lo señala.

La razón por la que sugiero esto es que:

1) La gente generalmente toma mejor la censura de las herramientas automatizadas que sus compañeros de trabajo o subordinados.

2) Estas herramientas cubren muchos problemas que pueden considerarse de estilo deficiente.

3) Es posible que pueda modificar las reglas detrás de la escena por su mal estilo más allá de lo que está integrado en la herramienta. Por ejemplo, imponer un cierto estilo de variable.

4) Algunas personas se dan cuenta de que su código no es tan bueno y en realidad comienzan a prestar más atención incluso a cosas que no están cubiertas por los linters.

Bastantes compañías bien respetadas (como mi propio empleador) obligan a controlar las pelusas antes de registrarse. La opinión es que el mal estilo es deuda técnica. Siempre se puede usar "Bueno, si X e Y y Z lo están haciendo, probablemente sea una buena idea".

Creo que definitivamente no debes decirle nada de eso directamente . Dichas declaraciones pueden provocar fácilmente una reacción defensiva en él, lo que seguramente cerrará cualquier posibilidad de aprendizaje, e incluso puede causarle problemas.

En su lugar, busque (e incluso intente crear) oportunidades para discutir casualmente el estilo de codificación y los problemas de idioma y mencionarle las "mejores prácticas" que conozca. Por supuesto, primero debe asegurarse de que lo que sugiere es una buena práctica ampliamente conocida y aceptada.

También, trate de discutir los mismos problemas con otros miembros del equipo también. Es importante entender el "consenso" (hablado o no) dentro del equipo con respecto al estilo y la calidad de la codificación . (Si todos los demás escriben códigos limpios y de alta calidad, tiene un caso muy diferente al de si el resto del grupo está formado por programadores reales que escriben con orgullo los programas de FORTRAN en cualquier idioma). También pueden contar más sobre los antecedentes históricos del proyecto. y el estilo de codificación de su jefe, que le ayuda a orientar mejor sus esfuerzos.

Otra forma es pedirle que ordene Java efectivo para ti, porque sientes que lo necesitas para Conviértete en un mejor programador. (En caso de que aún no lo hayas leído, de hecho lo necesitas). Luego puedes hablar con él sobre las maravillosas soluciones y prácticas de este libro.

Si está dispuesto a superarse a sí mismo, recogerá tus sugerencias (y el libro). Si no, puedes retirarte sin perder la cara y forzando tu relación.

Si tu jefe es un tipo genial, simplemente pregúntale: "¿Amigo, WTF?"

En todos los casos en los que pienses que "el mío es mejor" nunca le digas a alguien que piensas eso, muéstralo.

Repito, MUESTRE, no digas.

Ya sabes que decir sobre acciones, más fuerte, palabras ... es cierto.

¿Exactamente qué posición ocupa tu jefe? ¿Es un desarrollador, líder tecnológico? ¿Cuántos otros desarrolladores hay en la empresa? ¿La empresa tiene estándares de codificación y revisiones de código?

Es poco probable que logre que su jefe cambie sus malos hábitos (IMHO), pero podría usar un grupo de compañeros o los estándares de la compañía para influir en él. Si su código hace sigue los estándares y los compañeros son todos iguales, entonces sus opciones son limitadas.

Aquí está mi recomendación:

• Indique bien su caso.
• Si su administrador no es receptivo * a su punto de vista, y siente que tiene razón, busque pastos más verdes y no ponga excusas.

Te recomiendo que busques pastos más verdes por tres razones:

1. A largo plazo, es perjudicial para la carrera de un programador perpetuar las malas prácticas. La perpetuación de las malas prácticas engendra malos hábitos.
2. Un taller de programación que no es receptivo a puntos de vista alternativos ahoga la imaginación.
3. Cuando sabe que está perpetuando las malas prácticas y su equipo no es receptivo a puntos de vista alternativos, su moral está destinada a hundirse, y esto hará que su vida sea miserable. Así que deja lo antes posible.

* Distinción importante: esperar que alguien sea receptivo a tu punto de vista no es lo mismo que esperar que alguien arroje a tu punto de vista. Siempre aprecio a las personas que consideran mi punto de vista, mientras que tengo poco respeto por las personas que son suaves y ceden a mi punto de vista sin la razón o evidencia suficiente para hacerlo.

Las acciones hablan más fuerte que las palabras:

Un enfoque diferente:

• Necesitas liderar con un ejemplo.
• Asegúrese de que los proyectos que realice sean los mejores que puede hacer.
• Necesita sobresalir en términos de rendimiento, menos errores, etc.
• Una vez que pueda demostrar que su enfoque y estilo es mejor que su jefe, a menos que sea muy arrogante, creo que, naturalmente, esa persona seguirá lo que sea mejor.

Solo le daría Punteros en pequeñas dosis, cuando lo veas haciendo algo "malo"

"Hmm, mira este enfoque para eso {Apuntando a su pantalla}, me gusta hacerlo de esta manera debido a bla bla bla".

Haz esto No más de una vez cada dos días. Si él no acepta su sugerencia, nunca la vuelva a mencionar (por algunas semanas). Algunos se pegarán. Y poco a poco mejorará.

Pídele a tu jefe que compare con otra forma en la que te han enseñado. Él puede tener una razón legítima. No vas a saber hasta que lo pidas. Puede haber algún estándar de codificación antiguo que está tratando de mantener o simplemente no le importa. No dé ninguna indicación de que piense que el jefe está automáticamente equivocado. Ah, y hazlo en privado. Esto es para sus propósitos educativos.

Depende. Si el código que está revisando es nuevo, pídale que lo revise, ya que le ayudará a "ponerse al día" y mostrará que está interesado en aprender. El jefe puede encontrar esto útil, ya que le demostrará que estás buscando hacer lo correcto. Si este es un código antiguo con el que tropezó y se ve obligado a mantenerlo, haga un punto para hacer una refactorización lenta. Una declaración de tipo aquí y allá mientras se completa la tarea en cuestión. Ahora, el problema aquí es que la cadena YesOrNo puede asumir otros valores, como Maybe , lo que puede conducir a un código roto si no tiene cuidado.

Intente mostrarle fragmentos cortos de código de muestra de sitios / lugares / libros acreditados, etc. que logren cosas similares.

Lo primero que haría sería averiguar cómo reacciona ante los críticos. Si yo fuera el jefe, bueno, no haría nada malo, ¿verdad? - Preferiría que me lo dijeran directamente a la cara, todos a la vez, pero de una manera respetuosa. Dependiendo del temperamento y la cultura, tu jefe puede ser diferente.

Pero la mayoría de ellos necesitan algo de respeto. Una buena manera de demostrar que lo respeta es lo que se sugirió anteriormente: explique lo que quiere decir, pero déjele la decisión: "Esta es mi razón, pero quizás haya supervisado algo. Después de mi explicación:"

if (YesOrNo == "Yes")
if (YesOrNo == "yes")
if (YesOrNo == "YES")
if (YesOrNo == "oui")
if (YesOrNo.equals ("Yes"))
if ("Yes".equals (YesOrNo)) // might be null

"¿Qué sugiere usted ?"

Y puede hacer una pregunta previa antes: "Sr. X, si he encontrado algo en su código, lo que comúnmente se considera una práctica que se puede mejorar: ¿cómo debo informárselo? ¿Todo de una vez, o paso a paso? ¿O debería evitar mencionarlo a toda costa? ¿Mejorar el código en silencio? "

Dependería de mi relación, qué redacción elegiría y qué enfoque.

Su jefe no sabe cómo programar y no debe hacerlo. Mi experiencia me dijo que suponer que alguien llamado jefe también es más experimentado o mejor que tú es una falacia. Puede ser mejor en otras cosas, pero el punto de administración y jerarquía es delegar las cosas a la persona más apropiada. Un jefe es alguien que tuvo la oportunidad de iniciar un negocio, o llegó a ocupar un puesto gerencial, eventualmente por sus habilidades gerenciales, no necesariamente por sus habilidades de programación.

Una vez tuve un jefe que fingió haber instalado una computadora mientras estaba conectado a un generador eléctrico de gasolina, porque afirmó que los piratas informáticos podían ingresar a través de la red eléctrica mientras la máquina aún estaba desprotegida. Renuncié de inmediato. Aprendí una valiosa lección en ese entonces: el jefe no siempre tiene la razón y, a veces, renunciar es la única respuesta valiosa.

Entonces, para volver a su caso, es posible que tenga un caso donde solo buscar otro empleo (sí, crisis, yadda yadda ... Lo sé) puede ser la mejor cura. No pierdas tu precioso tiempo.

Vivo en la industria donde no puedo encontrar los errores de mi jefe. Así que, mejor, generaría los casos en los que aparecen errores en el código y le dejo ver el error, que le sugeriré los cambios necesarios y la posible razón [en su caso, está seguro de la razón ...: - D] del error. Cualquier desarrollador, ya sea bueno o malo, no aceptará el error hasta que vea el error.

Una vez tuve un gran problema con el estilo de un jefe.

Hay dos problemas con eso. En primer lugar, creo que nunca se lo dije a la cara, pero me imagino que él lo sabía. Se mantuvo profesional, no lo hice, IOW.

En segundo lugar, había razones para lo que hizo, y solo me llevó tiempo comprender cuán "sobrecomplejadas y desagradables eran mis" soluciones de esta manera es correcta ".

De los tres puntos de la pregunta, los diacríticos no son extraños para todos, y si bien no lo usaría para el bucle, me molesta la familia C ... mientras que la sintaxis y cómo (no ) encaja con mi estilo de sangría, así que tal vez pueda ver de dónde viene.

Incluso lo booleano podría tener una explicación en términos de hábitos traídos desde otro idioma (lo cual no es una justificación, por supuesto).

Supongo que esto podría funcionar -

1. Pídale a su administrador que revise su código, el cual no tiene ninguno de los errores que cometió.
2. A continuación, vea si su gerente le pregunta por qué no lo hace "su" manera
3. Si él hace esta pregunta, podrías preguntarle por qué sería una mejor manera.

De esta manera, puedes saber por qué piensa que su camino es correcto.

He estado allí antes. Salí de Uni y luego de un año de trabajar para un chico, me di cuenta de que sabía mucho más que él sobre programación, pero era asunto suyo, y él hizo todo lo que pudo, y no quería ofenderlo. ¡de todas formas! Decidí que la mejor manera de evitarlo era discutir los beneficios de tener convenciones comunes de codificación en toda la empresa para que todos también nos mantengamos firmes, y ver cómo reaccionó. Sorprendentemente, pensó que era una gran idea, y me pidió que elaborara una lista de estándares, que los dos revisáramos juntos y termináramos, etc.

Lo importante aquí es que eres tan falible como él, y que solo porque algunas de sus formas son extrañas / incorrectas, algunas serán mejores que las tuyas.

Desde mi experiencia personal, sin embargo, no funcionó. A pesar de haber pasado 2 días investigando y compilando un gran documento de estándares y convenciones de codificación, él ya estaba decidido, no veía realmente el beneficio de las convenciones de codificación, ni escribía un código que pusiera menos presión en el servidor, lo que hizo que nuestros trabajos Más rápido y fácil, y reducir costos.

Al final me fui para encontrar un lugar que tomara el desarrollo un poco más serio. No todo fue malo, ya que la investigación que hice sobre las convenciones de codificación realmente ayuda hasta el día de hoy.