Después de casi dos años, Senior sigue sugiriendo cambios no solicitados que rompen el código.

Solía ​​ser un Junior en mi trabajo. El senior de 25 años que se sentó a mi lado se acercó a mí y me hizo sugerencias sobre cómo cambiar y reordenar mi código... Inicialmente lo tomé al pie de la letra y traté de implementar sus sugerencias, pero he encontrado las sugerencias que él hace que por lo general rompa totalmente o, en el mejor de los casos, degrade la calidad de mi código.

Me llevo bien con Senior a nivel personal y, a veces, logra cosas valiosas con su propio código, de alguna manera extraña porque a menudo parece estar diciéndome que implemente prácticas que él evita en su propio código. Las conversaciones en torno a esto están ocupando cada vez más mi tiempo hasta el punto de casi interponerse en el camino de mi producción para la tarea.

Hoy llegamos a un punto en el que, después de rechazar numerosas sugerencias por considerarlas impracticables o por centrarse en pulir las minucias a expensas de MVP, llegamos al punto en que él dijo "sí, pero si terminas esto tú mismo, ¿qué pasará?" otras personas tienen que hacer?".

Hay mucho más por hacer de lo que posiblemente se podría hacer y siempre hay mucho por hacer, e incluso le sugerí que podía contribuir a la tarea si quería, algo que no parecía muy interesado en hacer.

Después de dos años, en el momento en que pronto seré Senior, otro desarrollador comenzó a bromear sobre cómo cuando este Senior lo 'ayuda', quiere morir. Una mujer mayor dijo 'él está bromeando, pero en realidad no lo está'.

Como dije, me llevo bien con él en general, pero estoy ansioso por resolver este problema antes de que se intensifique. ¿Cuál es la mejor manera de tratar?

¿Cuánto tiempo llevas con la empresa?
¿Él sabe que están causando que tu código se rompa? ¿También podría estar fallando porque hay un problema de diseño con su código?
@cgTag, perdóname por ser quizás un poco paranoico, pero la gente me pregunta muchas cosas como esta, y otras preguntas como '¿quieres deshacerte del Junior en el título de tu trabajo?' así que necesito decir: no estoy buscando cambiar de trabajo o mudarme a otra compañía en este momento. Pero si su pregunta es real, como estoy seguro, y tiene la intención de ayudarlo a responder mi pregunta: seis meses.
@PeterDavidCarter En los primeros meses, la gente tiende a explorar la nueva cultura laboral. Aprenden durante este tiempo lo que son las políticas. (quién está realmente a cargo, por qué y cómo me salgo con la mía). Tuve la sensación de que el mayor estaba volando en helicóptero sobre ti porque eras un nuevo miembro del equipo. 6 meses es aproximadamente el tiempo que esperaría que él / ella comenzara a retroceder. Creo que puede pedirle con seguridad que le dé más libertades, o discutir esto con Recursos Humanos. Por la pregunta supuse que acababas de empezar.
@cgTag era nuevo en nuestro equipo, que supuestamente es un buque insignia de nuestra empresa, aunque con una alta proporción de jóvenes, algunos de los cuales vinieron de puestos más altos para unirse
"Sí, pero si terminas esto tú mismo, ¿qué tendrán que hacer otras personas?" - ¿podría haber sido una broma tal vez? Suena como uno...
Si todo son bromas, parece extraño que se expresen de manera seria y que se insista en que se sigan las sugerencias. Particularmente porque tales insistencias tienden a variar según el grado de problemas con el propio trabajo de esta persona. Por supuesto, hasta cierto punto, la declaración particular que cita es una broma, pero esconde un punto serio debajo del humor. Personalmente, no hago bromas que tengan el potencial de causar problemas con el producto a menos que esté seguro de que se interpretarán como tales. Hubiera esperado que esa fuera la opinión de todos.
No estaré de acuerdo con la mayoría de las respuestas. Tal vez esté tratando de sabotearte. ¿por qué? porque me pasó a mí. Tengo esa cara tonta/neutral (tengo 28 años y parece que tengo 20). Después de 5 años conseguí un nuevo trabajo con un senior (todos saben que es realmente un compañero de trabajo de mierda). Pensó que yo era un administrador de base de datos sql junior, tonto. Sabía que era una "falsa persona" (no conozco este término en inglés) porque era esa persona tranquila y pacífica. No me equivoqué. La primera "tarea" que me dio noté lo estúpido que era. Rompería todo y lo hizo a propósito. 2 años con eso. Tengo un nuevo trabajo.
@GreenBaloon no se trata de que las personas sean estúpidas, se trata de que usen toda su energía cerebral tratando de bloquear a otras personas en lugar de hacer lo que están haciendo o ayudar a los demás. Al final eso se interpone en el camino de la progresión.
@PeterDavidCarter Hay un estilo de humor en el que los chistes se cuentan a propósito con una voz muy seria, dejando que la audiencia "entienda". Incluso hay un nombre para esto (que se me olvidó). Lo hago bastante a menudo de forma natural.
@ig-dev Creo que el término en el que estás pensando es inexpresivo .
Creo que luego le diré, según su consejo: aumente la temperatura del reactor central tanto como desee. Todos morirán, pero algunos se ríen.
¿Desde cuándo dos años te hacen senior?
@Kabard Parece que eso sucederá pronto
@Kabard si no, tengo mi proyecto personal y algunas personas trabajando debajo de mí que me respetan cuando digo algo
@JoeW Si cambio el código y lo rompo, eso nunca es un problema de diseño. Es un problema conmigo tocando cosas que no entiendo. Si hay un problema de diseño que hace que las cosas se rompan cuando se cambian, entonces no cambio el.

Respuestas (5)

Soy un Junior en mi trabajo. A menudo, recientemente, el Senior que se sienta detrás de mí se acercó a mí y me hizo sugerencias sobre cómo cambiar y reordenar mi código...

Él está dando un consejo de puño. Él está tratando de ayudarte, pero no está haciendo un buen trabajo.

Inicialmente lo tomé al pie de la letra y traté de implementar sus sugerencias, pero descubrí que las sugerencias que hace generalmente rompen totalmente o, en el mejor de los casos, degradan la calidad de mi código.

La calidad del código es muy subjetiva.

¿Tiene su departamento de I+D documentación que describa la calidad del código?

Mi experiencia ha sido que los juniors no traducen los consejos de los seniors en aplicaciones prácticas. Mucho se pierde en la traducción y hay una falta de puntos en común para llenar los vacíos.

Tal vez te está diciendo que implementes "A" y has implementado "B". Puedes ver que "B" no es realmente tan bueno. Sientes que tu trabajo fue desviado y luego viene y dice que debes implementar "C", pero nuevamente implementas "D". No puedo culparte por frustrarte.

Es un problema de comunicaciones.

Documento, documento, documento.

La próxima vez que ofrezca un consejo, pídale que lo ponga por escrito. Utilice el correo electrónico, un documento o un rastreador de errores, pero consígalo por escrito. Respóndele con tus preguntas pero trata de organizar tus preguntas en una sola respuesta. Incluya ejemplos de código fuente, archivos de referencia o proporcione enlaces a Internet para verificar qué patrones de diseño deben seguirse.

Si no proporciona una versión escrita de su consejo, entonces escríbalo y se lo envía para que lo revise. Pida aclaraciones sobre cualquier cosa que no esté clara.

Obtenga todo por escrito.

Programación en pareja

La próxima vez que se te acerque, pídele que se siente a tu lado. Entrégale el teclado y el ratón. Pídale que demuestre lo que quiere decir. Pídele que escriba parte del código fuente. Pídele que se quede mientras pruebas algunos de sus consejos. Déjalo ver cómo te causa problemas . Dale la oportunidad de explicar cómo solucionarlo .

Pídele que regrese y hazlo de nuevo . Aprende a escribir código juntos.

Curiosamente, nosotros, como equipo de desarrollo, nos estamos adelantando a lo que nuestro equipo de control de calidad tiene recursos para probar. Entonces, "¿tiene su departamento de I+D documentación que describa la calidad del código?" es un comentario muy interesante. Ahora tenemos SonarQube, pero se han tenido muchas conversaciones sobre la evaluación de la calidad del código en un nivel objetivo.
@PeterDavidCarter, debe escribir pautas cada vez que intente hacer cumplir algo que es muy subjetivo. Herramientas como Sonar son una forma de documentación. Se convierte en una autoridad a la que puedes decirle a otros desarrolladores que también se refieran, pero no explica todo. Como cultura empresarial, ¿qué valoras? ¿Mantenibilidad del código, desarrollo de conejos, estabilidad del producto, programadores con salarios más bajos, tutoría senior, costos y tiempos del proyecto? Estos impulsan la calidad del código fuente, pero lo que es más importante, los desarrolladores deben comprender por qué lo impulsa.
tienes razón: poder trabajar con otras personas, integrar su trabajo y llevar un proyecto a un nivel profesional es clave. Cualesquiera que sean las palabras de moda que se pongan alrededor de eso, eso es lo que tienes que ser capaz de lograr.
Esto ha ocurrido repetidamente durante casi dos años y sigue ocurriendo. No es un accidente. Es una estrategia de un mal codificador que llegó a donde está saboteando a todos los que ve como una amenaza.

Puede que me equivoque en esto, pero me parece que tu superior solo está bromeando contigo. Tanto las sugerencias de cambios que rompen el código como el comentario frívolo de que nadie más tiene trabajo que hacer me suenan a sarcasmo.

La respuesta sería reírse y continuar escribiendo código (bueno).

Debido a que es un junior, es posible que no se dé cuenta de que los cambios de código sugeridos son malos hasta que los haga. En este caso, pregúntale si habla en serio cuando no estés seguro.

Tal vez el mayor sea ingenioso y OP sea un blanco fácil. El senior probablemente esté escribiendo una publicación en alguna parte "He estado bromeando con este junior durante dos años y todavía no lo entiende".
@ig-dev En ese caso, el senior necesitaría una gran patada. Hacer esto intencionalmente es solo intimidación. Y la empresa no estará contenta si descubren que está saboteando el trabajo de un compañero de trabajo.

En mi humilde opinión, mueva su vía de sugerencias a un medio rastreable y sepárelo de las interacciones personales, donde dice que se lleva bien.

Dígale que le envíe un correo electrónico debido a que actualmente está un poco ocupado para comprender toda su sugerencia.

Créeme, obtendrás quizás el 10% de lo que tienes ahora de él.

Simplemente ignore las sugerencias que no mejoren su código, simplemente ignoraría todo después del primer fiasco o dos.

Continúe con lo que sabe y tome sus comentarios para mejorar de las fuentes normales, como revisiones, etc.

La antigüedad no significa automáticamente mejor o incluso más informado. La experiencia laboral de muchas personas es de calidad inferior, incluso si han estado en una industria durante décadas.

Simplemente ignore cortésmente las sugerencias, no es un concurso de belleza y la popularidad no es un enfoque principal por encima de hacer un trabajo sólido y avanzar en su carrera profesional. Después de un tiempo, encontrará a alguien más a quien molestar.

Esto puede ser una cosa cultural. En algunas culturas, las “sugerencias” se toman como órdenes y no seguirlas sería muy conflictivo. En otras culturas, hacer sugerencias muestra que estás interesado, pero las ignorarías a menos que creas que son una buena idea.

Es posible que el senior ni siquiera se dé cuenta de que sigues las sugerencias en contra de tu mejor juicio. Te sugiero que estés abierto a sugerencias, pero siempre haz lo que creas que es mejor a menos que alguien te ordene lo contrario y se responsabilice por ello.

Sí. Esto es cierto. La persona en cuestión se ha enfadado mucho en el pasado por 'romper la cadena de mando' pero, irónicamente, la gente en la parte superior de la cadena (a pesar de que yo estaba un poco loco y era un imbécil con ellos en numerosas ocasiones) se han puesto de mi lado y los cambios importantes en la aplicación no se han restaurado en todas las instancias recientes.