¿Cómo manejaría los estándares de codificación incorrectos e inflexibles en un nuevo trabajo? [duplicar]

Solo he estado trabajando en mi puesto actual durante un poco más de 3 meses y siento que algunos de los estándares de codificación que existen van en contra de mis mejores prácticas personales. El conflicto más grande parece ser cuando escribo código SQL, me gusta hacer que mi código sea muy legible, fácil de entender y fácil de probar, pero aparentemente eso no es parte de los estándares aquí y me piden que elimine los elementos que puse en su lugar para promover mis mejores prácticas, lo que nuevamente lo hace más fácil y rápido para mí y estoy seguro de que otros que vienen detrás de mí lo entenderán y probarán.

El ejecutor es mi gerente y es muy estricto con los estándares y hace que sea casi imposible pronunciar una palabra e ignora por completo cualquier razonamiento detrás de mis acciones y retrocede a "esto no son estándares". ¿Por qué no pueden ser entonces? ¿Por qué no hacerlos estándar? ¿Qué tiene de malo tener un código fácil de entender que hace que sea fácil de probar y modificar?

La otra parte de mi frustración proviene de sentir que soy la única persona a la que se le imponen estos estándares. He encontrado muchas veces un código que me da escalofríos y que aún no coincide con nuestros estándares... existe y se escribió recientemente.

En este momento, esta es mi mayor preocupación con el lugar donde estoy trabajando, me gusta que tengamos estándares y que se cumplan, pero no estoy investigando la inflexibilidad y la mentalidad cerrada de los estándares y se está volviendo muy frustrante.

Además, comencé a escuchar una nueva línea esta mañana, "[Nombre del director] no le gusta...", aunque ya no está escribiendo código y siento que su estilo de codificación personal no debería dictar una posible mejora en los estándares.

¿Qué harías? Siento que estoy atrapado entre la espada y la pared.

Sin embargo, esta publicación trata menos sobre cuáles son mis estándares y más sobre cómo manejar un conflicto de estándares, especialmente cuando siente que obstaculizan la velocidad con la que trabaja.

No puedo decir si está pidiendo ayuda con los estándares de codificación (fuera de tema aquí, intente Programadores), o si está preguntando cómo persuadir a su gerente para que cambie (en cuyo caso los problemas de codificación detallados distraen un poco ). En cualquier caso, las discusiones sobre los estándares de codificación de SQL no pertenecen a los comentarios aquí (porque se tratan de estándares de codificación de SQL y porque son discusiones), así que los eliminaré. Sugiero editar su pregunta para centrarse en el aspecto específico del lugar de trabajo. Gracias.
Estoy de acuerdo y actualizaré cuando pueda.
Recuerde que los estándares de codificación consisten en establecer convenciones en todo el código base, de modo que el programador que tendrá que mantener el código cinco años después de que usted haya dejado la empresa no tenga que averiguar las convenciones idiosincrásicas de cada programador. No se vuelve menos eficiente al seguir los estándares; básicamente, está invirtiendo ese tiempo en documentar su trabajo. (Sí, un buen programador debería ser capaz de leer cualquier estilo común. Por otro lado, he visto algunos programadores que, abandonados a sí mismos, escribieron un código tan idiosincrásico que rompió el depurador).
@Tony: vea mi pregunta sobre ser nuevo y abogar por el cambio (¿ Qué tan pronto debo abogar por hacer cambios después de comenzar en un nuevo trabajo? ). Podría ser útil

Respuestas (5)

No eres un copo de nieve especial ni trabajas en el vacío

mis mejores practicas

A menos que sea su propio gerente, no puede dictar qué estándares usar. E incluso si es así, es probable que trabaje para otros y aún deba cumplir con sus estándares.

Esta es una parte significativa de la realidad de trabajar para otros.

También tenga en cuenta que los estándares tienen mucha historia en muchos casos. Tal vez algún desarrollador anterior hizo algo que causó muchos problemas cuando el desarrollador se fue. Quizás un gerente tuvo un viaje de poder. Esto nunca será claro de inmediato, especialmente como una persona nueva.

La otra parte de mi frustración proviene de sentir que soy la única persona a la que se le imponen estos estándares.

Sospecho que esto se debe en parte, si no en su totalidad, a tu actitud. Hay muchos factores además de simplemente su trabajo que afectan la perspectiva de sus jefes sobre usted.

En este punto, es probable que tu jefe sienta que eres un empleado problemático. Todo en tu pregunta dice: "Tengo razón, ¿por qué los idiotas con los que trabajo no me entienden y me creen? ¡Es tan obvio!"

¿Qué harías?

Si desea tener una influencia significativa en su lugar de trabajo, aprenda a "jugar" a la política de oficina.

Otra verificación de la realidad: si desea comenzar a influir en las personas, debe hacerlo de manera efectiva. Esto significa que las habilidades de la gente son más importantes que el conocimiento técnico. Antes de estar en desacuerdo con esto, tenga en cuenta que toda su pregunta es el resultado de este problema: si las habilidades/perspectivas técnicas fueran de suma importancia, no habría tenido que hacer esta pregunta.

Este es el temido componente de "política" del trabajo que la mayoría de los técnicos evitan.

Un componente clave de la política es darse cuenta de que el "cómo" es más importante que el "qué".

Las personas olvidaran lo que dijiste

La gente olvidará lo que hiciste

Pero la gente nunca olvidará cómo los hiciste sentir.

Una persona nueva que discute con la gerencia (especialmente si los directores se involucran) no es un buen cambio de carrera, casi nunca. Esto es diferente a estar en desacuerdo constructivamente.

Pasos de acción

  1. Hable con su gerente. Indique que lamenta discutir y pregunte si puede hablar sobre los estándares actuales.
  2. En esta conversación, deja de discutir. Comprenda el "por qué" de lo que sugiere su gerente. No asumas automáticamente "eres un idiota"
  3. Escuche lo que dice su gerente sobre "por qué". Si no entiendes esto, trata de entender el por qué, ni siquiera intentes estar en desacuerdo o decir "pero, pero, pero". La gente generalmente se pone a la defensiva cuando la gente discute con ellos. Y esté mucho más dispuesto a escuchar si escucha y busca comprender primero.
  4. Después de comprender completamente por qué su gerente quiere estos estándares (probablemente debería decir algo como: "Entonces, si entiendo correctamente, las razones de estos estándares son X, Y, Z"; si no puede hacer esto, necesita más información) , pregunte algo como: "¿Estaría bien si explico lo que he estado haciendo y por qué para determinar si podrían incluirse en el estándar?"

Anda con cuidado en esta conversación. Si tiene algún nivel de discusión, es probable que pierda mucho, dado que tiene antecedentes con su gerente.

Buena publicación, mi actitud aparentemente me ha tergiversado de las respuestas que he recibido hasta ahora, pero a pesar de todo, todavía veo valor en esta respuesta. Para ser claros, no discuto con la gerencia ni con nadie. Mi gerente me felicita constantemente por mis habilidades, la calidad del trabajo y, sí, incluso mi capacidad para seguir los estándares más que los demás. Mis habilidades con las personas no son malas, aunque principalmente me quedo con la cabeza baja y simplemente pirateo el código. Sin embargo, tengo una debilidad por la política y acepto que necesito aprender a jugar mejor.
@Tony, a veces, el principal problema que tiene la gente es reconocer que su actitud es hostil/discutible. No puedo contar la cantidad de conversaciones que he tenido, ya sea sobre mí mismo o sobre otros, que básicamente dicen "eres muy conflictivo" seguido de "¿en serio? ¿Cómo es eso?" Esto también es una gran parte de la política, comprender el impacto/la imagen que presentas.
@Tony, también vale la pena señalar que eres bastante nuevo en la empresa. Por lo tanto, su capacidad para influir en el cambio es limitada. Yo, al igual que tú, soy el tipo de persona que ingresa a una empresa y continuamente sondea y empuja para tratar de cambiar las cosas en una mejor dirección. Diré que es un baile muy delicado políticamente hablando, y es casi enteramente política. Cualquier cambio que intente hacer se encontrará con algún tipo de resistencia, algunos serán fáciles de superar, otros serán una larga campaña de desgaste para desgastar a la oposición. Elija sus batallas, una pelea a la vez, avance con cuidado y mantenga las métricas.
Marcando esto como la respuesta, ya que creo que estuvo bien escrito a pesar de algunos conceptos erróneos y proporciona algunos buenos comentarios en general que otras personas en otras industrias también podrían encontrar útiles.
@Tony, también puede encontrar útil esta pregunta .
La oración del título debe ser el eslogan del sitio, o estar rellenada previamente en el cuadro Hacer una pregunta, o algo así :)
Estoy de acuerdo con esto, excepto que ni siquiera lo elevaría al nivel de "política". Desde mi punto de vista, la política consiste en comprender (y tal vez manipular) las diversas relaciones entre un grupo de personas. Se trata solo de la capacidad básica de interactuar con una persona (tu jefe) de una manera vagamente productiva :-)

Excelentes respuestas anteriores, pero me gustaría agregar un punto más.

Bueno malo o no, hay una historia de estos estándares. Si se siguen, es probable que haya una base de código significativa escrita para estos estándares. Su solicitud de cambiar los estándares crearía la necesidad de revisar todo el código base para reestructurar el código anterior. Esto podría ser un esfuerzo significativo y agrega riesgo de cambios de código involuntarios. Si el equipo no toca el código anterior, ahora se va por dos (o más) estándares.

En mi experiencia, si tiene más de un estándar, probablemente no tenga ninguno.

Cada vez que se introduce un nuevo estándar, este estándar generalmente no se aplica al código heredado hasta que este código heredado requiere una actualización lógica (es decir, una nueva característica o una corrección de errores). Cambiar el código solo para adherirse a un nuevo estándar es peligroso e irresponsable.
Estoy de acuerdo con el código heredado, pero hay muchos proyectos actuales que tienen un historial de varios años que podrían verse afectados. Una de las aplicaciones que mi equipo ha creado y que actualmente está mejorando tiene más de 200 000 líneas de código. Si alguien sugiriera un nuevo estándar para ese código, la respuesta probablemente sería no.
Estoy de acuerdo, y los estándares parecen seguirse muy libremente aquí, excepto cuando se trata de mí. Sigo recibiendo la línea "otros antes que yo no los hicieron cumplir, pero yo sí", lo cual está bien, pero todavía veo que el código proviene de otros que no se ajustan en absoluto. Los estándares que busco ni siquiera cambiar, solo pido que lo permitan, simplemente se basan en comentarios, lo que permite una comprensión más rápida. Aunque estoy de acuerdo con lo que has dicho.

Sé que esto no es lo que quieres escuchar, pero la triste verdad es que las empresas (o más bien las personas que las dirigen) no siempre siguen la lógica o la "mejor manera". Esto se debe a una variedad de razones, algunas razonables (compatibilidad, cumplimiento, estandarización, etc.), otras no (miedo al cambio, falta de comprensión, etc.).

La otra verdad desafortunada es que no siempre estás en condiciones de cambiar eso. Algunas cosas nunca cambiarán, otras cosas en las que puede influir con el tiempo. Lo que diré, sin embargo, es que usted es un nuevo miembro del personal y está claro que hay una fuerza impulsora real para hacer las cosas de una manera particular. Mi sugerencia sería amoldarse a estos, te gusten o no, y evaluar tu posición cuando estés más integrado en la empresa.

Iniciar una pelea con la alta dirección y los líderes de la empresa es un juego peligroso en el mejor de los casos: incluso cuando estás en la cima del árbol técnico, las personas que poseen y dirigen la empresa pueden (y a veces lo harán) gobernarte. Hacerlo cuando eres nuevo está al borde del suicidio.

Estoy de acuerdo, no discuto y me ajusto a los estándares (las 30 páginas de los estándares C# y SQL que se han establecido). Mi frustración es cuando siento que los estándares obstaculizan mi desempeño. Sin embargo, honestamente, la gerencia no es consciente de mi frustración, ya que realmente no lo he verbalizado. Solo asentí con la cabeza y dije que sí, está bien, arreglaré eso, posiblemente después de preguntar por qué, pero la mayoría de las veces soy indiferente y simplemente lo cambio como soy nuevo. y sigo aprendiendo todos los estándares, pero rara vez me corrigen porque los sigo bastante bien. ¡Buena respuesta!

El hecho de que la razón de un estándar no sea visible no significa que sea irracional.

Si bien estoy de acuerdo con todo lo dicho anteriormente (sobre los nuevos empleados que necesitan maximizar sus habilidades con las personas y aprender la política de la empresa local), una cosa que puede ayudar a reducir su nivel de frustración es comprender que algunos estándares de codificación no se basan tanto en ilógicos y arbitrarios . factores, sino más bien en los válidos pero invisibles .

Considere su ejemplo que describió como

"Un estándar WTF más con el que acabo de pasar pero parece completamente inútil"

De hecho, he visto este estándar exacto en dos organizaciones diferentes y había una razón muy válida para ello.

En ambos casos, descubrí que la gerencia estaba usando cierto software para analizar el proceso de desarrollo y evolución del código y este software tenía expectativas estrictas de cómo se formatearían los comentarios (también conocidos como estándares). Las líneas de "TICKET" que describe pueden incluir solo " comentario: " en su departamento, pero más adelante en la línea de producción pueden surgir incidentes en vivo que requieran la resolución de problemas y la modificación del software. Los técnicos y la gerencia involucrados en esos eventos pueden agregar líneas de TICKET con cosas como " problema: ", " arreglo: ", " cambio: ", " referencia: ", " evidencia: ", " decisión:". Si lo asignan para trabajar en la reparación/actualización del código heredado, es posible que usted mismo vea algunas líneas como esa.

Una cosa concreta que puedo sugerirte es que intentes aprender algo llamado "ITIL" y/o "ITSM". Estas son colecciones de mejores prácticas de clase mundial para TI, tanto desde un punto de vista técnico como desde una perspectiva de gestión al mismo tiempo. No bromeo que puede ser muy difícil entenderlos al principio si usted es un experto en tecnología (no administrativo), pero a la larga mejorará drásticamente su capacidad de ver el "panorama general" y puede considerarse un Habilidad comercializable y/o promocionable si decide ir tan lejos como para obtener la certificación ITIL.

+1 para valid-but-invisible. Especialmente para un nuevo empleado.
Estoy de acuerdo con la parte válida pero invisible, pero la parte triste es que ninguna persona está usando este formato de comentario nuevamente, solo me obligan a ver a otros dejar comentarios sin siquiera un número de ticket o una descripción real de lo que dicen. haber hecho. Como se mencionó en otros lugares, honestamente siento que soy el único que esperan seguir algún estándar solo porque soy nuevo, mientras que otros pueden tener un servicio gratuito para todos. ITIL me entristece, hay una larga historia detrás que no compartiré aquí. ¡Solo decir una presentación de 8 horas con alguien hablando contigo hace que el día sea largo!
Me gusta lo que mencionaste sobre las otras variaciones que posiblemente podrían ir con la idea del boleto, para mí, la parte del comentario tendría mucho más sentido si estuviéramos usando un conjunto como lo has descrito, en realidad me hace más fácil de tragar.

Todos los buenos consejos son: el chico nuevo no debe hacer olas, etc. y sí, a veces es mejor taparse la nariz y seguir los estándares, la política, etc.

Pero a veces la gestión se equivoca; a veces los 'estándares' de una empresa son realmente malos o peores.

En ese caso, busque otro trabajo; una larga experiencia me enseñó que es imposible arreglar una organización disfuncional. Esos lugares tienen una cultura de auto-reforzamiento, y si te quedas allí por mucho tiempo, también te arruinarás.

Explique en todas las entrevistas de trabajo la forma en que desea un nuevo trabajo, de esa manera es mucho menos fácil que vuelva a tener el mismo problema :-)
Si estoy de acuerdo. Mi problema es que salto de trabajo con demasiada frecuencia. Siempre terminan jodiéndome o encuentro algo con lo que no puedo lidiar. Siendo solo 3 meses, estoy TRATANDO de aguantar aquí. Desafortunadamente, este no es el único problema, pero en el momento en que escribí esta publicación, fue el problema más ofensivo jajaja. Sin embargo, estoy totalmente de acuerdo, los zombis que comen cerebros son malos.
¿Cómo manejaría los estándares de codificación incorrectos e inflexibles en un nuevo trabajo? [duplicar]
RespuestasAquíPolítica de privacidad1y, 0v