Mi compañero de trabajo es un buen tipo, pero su desempeño es bajo. ¿Le digo a mi jefe? [cerrado]

Hace unos tres meses me asignaron a un proyecto que hasta ese momento estaba en desarrollo por un único desarrollador recién contratado porque se estaba quedando atrás. Para ser justos, el proyecto es una interfaz para un dispositivo médico que tiene muchas sutilezas y es relativamente complejo, por lo que colocar a una persona en el proyecto que no tenía experiencia en la empresa probablemente fue una mala decisión desde una perspectiva gerencial.

De todos modos, una vez que comencé a trabajar en ello, me di cuenta de que ... bueno, simplemente no funcionó en absoluto. La interfaz de usuario se veía bien, pero en realidad no hizo mucho de nada, y lo que hizo fue hacer incorrectamente. Nuevamente, para ser justos, gran parte de esto se debió al hecho de que este desarrollador no estaba preparado adecuadamente para escribir una interfaz en nuestro dispositivo. Sin embargo, también me di cuenta rápidamente de que el código que estaba en su lugar era frágil y extremadamente difícil de mantener.

Ahora no pretendo ser el mejor programador del mundo. Trabajo con muchas personas muy inteligentes que son mejores desarrolladores que yo. Sin embargo, me esfuerzo mucho para escribir código que sea lo más simple y robusto posible. Pruebo mis registros. Si veo que mi código se está volviendo desordenado y difícil de trabajar desde el principio, lo cambio. He tenido algunas conversaciones con mi compañero de trabajo en un intento de ayudarlo a escribir un mejor código. Esto es un poco complicado porque a) tiene más de 20 años de experiencia en el campo y yo solo tengo 5, yb) fue contratado como un llamado "experto en UX" y otros lo ven como un individuo experimentado.

Dicho eso, simplemente no lo veo. Es un tipo muy agradable y es razonable, sin embargo, una y otra vez revisa un código que es frágil, funciona solo en los casos más optimistas y 9 de cada 10 veces termino arreglando errores en su trabajo. Su código solo parece aficionado y obviamente no tiene el nivel de experiencia que afirmó tener cuando fue contratado. Ha llegado el momento en que las horas extra que paso refactorizando su código y reparando sus errores me han afectado. A mi modo de ver, tengo dos opciones:

1. No haga nada, rompa mi trasero para asegurarse de que este producto salga a tiempo y sea robusto y espere a que falle en el futuro (no trabajaré con él en este proyecto después del lanzamiento inicial).
2. Cuéntale a mi jefe sobre su actuación. Mi jefe es un hombre razonable, pero me siento incómodo con este enfoque. No me gusta 'golpear' (por falta de un término mejor) a mis compañeros de trabajo y no sé cómo lo tomará.

Entonces, eso es todo. He intentado resolver esto con mi compañero de trabajo explicando por qué su implementación no funcionará o cómo se podría hacer que su código sea más fácil de mantener, pero continúa cometiendo los mismos errores. Estoy muy interesado en escuchar cómo otros han manejado situaciones similares, especialmente las personas en la gerencia actualmente. Gracias de antemano por cualquier consejo que me puedan ofrecer.

Al menos consideraría la posibilidad de que si fue contratado como un tipo de experiencia de usuario, es muy posible que nadie realmente espere un código realmente bueno de él; pueden esperar que su código solo sea básicamente un prototipo que describa la experiencia de usuario, y depende de otros codificadores escribir código de producción basado en eso.

Ahora, ciertamente no estoy diciendo que ese sea el caso, pero no me parecería terriblemente sorprendente. Al menos en mi experiencia, no es raro que la gente de UX produzca principalmente cosas como prototipos y guiones gráficos. En todo caso, si el tipo realmente fue contratado específicamente como especialista en UX, estoy alucinado por la noción de su código de registro. Estoy bastante seguro de que nunca he visto eso hecho.

Si el tipo realmente es un especialista en UX, la cura puede no ser tratar de lograr que produzca un mejor código, sino sacarlo completamente de la codificación (al menos todo menos prototipos). Si es honestamente bueno en el diseño de UX, el verdadero error es probablemente incluso pedirle que escriba un código de producción. En cambio, probablemente debería estar (como máximo) trabajando en un entorno limitado de prototipos UX donde su resultado se usa para guiar la próxima ronda de código real que se produce, pero nunca se registra como código de producción.

Intento tener una regla que siempre mantenga a mi jefe informado de las cosas que afectan el proyecto. Positiva y negativamente ... y en casos como este, trato de culpar a cosas como el código en lugar de a la persona que lo escribió. Suena mucho menos como si estuvieras golpeando a un compañero de trabajo y más como si estuvieras tratando de mejorar la calidad del producto.

Desde el punto de vista de la gerencia, hay 3 formas comunes de tratar con los empleados en esta situación:

1. Ten sus debilidades bajo control
2. Jugar a sus puntos fuertes
3. Deshazte de ellos (no es realmente tu elección)

Controle sus debilidades buscando ayuda externa.

Hola jefe, estoy un poco preocupado por el estado del código ... es bastante frágil y se rompe mucho. Tomará algo de trabajo llevarlo a un estado en el que sienta que se puede confiar. ¿Existe la posibilidad de que me preste uno de los arquitectos por un día o dos para ver si podemos llegar a un buen diseño?

No está pidiendo que otra persona se una al proyecto, está pidiendo más 'aportes de expertos' por un corto período de tiempo. Produzca cualquier documento que necesite, diagramas UML y fragmentos de código si eso es lo que quiere el arquitecto. Verán en qué estado se encuentra el código y luego su jefe hará que alguien más se haga eco de sus opiniones.

De la reunión, es de esperar que obtenga un mejor diseño que tanto usted como el otro desarrollador puedan seguir sin que él lo arruine mucho. Esto es lo que los diseños y las especificaciones requieren en muchos casos: reducir el daño que pueden hacer los malos desarrolladores.

Jugar a sus puntos fuertes

Hola jefe, estoy trabajando con el código para el proyecto x, y es magnífico. El código, por otro lado, podría usar un poco de trabajo. Creo que el proyecto estaría mejor si [ux guy] pudiera concentrarse más en la experiencia de usuario, mientras realizo algunas refactorizaciones para lograr un estado más estable. Una vez que el UX es sólido, el proyecto b probablemente podría usar su toque de Midas.

Aquí, es probable que tu jefe lo vea bien; que le estás diciendo que el otro desarrollador no es muy bueno ... pero al menos no estás siendo un imbécil al respecto. Y si honestamente es realmente bueno en el trabajo de UX, entonces podría encontrar una posición estable para saltar a cada proyecto y hacerlos excelentes desde el punto de vista de la usabilidad. Me imagino que también le gustaría más así.

Deja de arreglar repetidamente sus errores. El no aprenderá; Sé que no lo haría.

La programación es en gran medida una tarea lógica, pero también implica la recolección de memoria. Cuando a menudo escribe código común, recuerda cómo implementó la solución la última vez , en lugar de resolverlo nuevamente. Si nunca ha implementado el código correcto, puedo ver por qué sigue repitiendo los mismos errores.

Muéstrele lo que hizo mal, y quizás lo arregle la primera vez. Para cualquier otra ocurrencia del mismo incidente, pídale que implemente la solución que le mostró.

Tendría mucho cuidado por algunas razones:

1. ¿Cómo estás seguro de que no trabajarás con él después del lanzamiento inicial? Su gerencia podría pensar, "¡Qué equipo, miren cómo entregaron esta maravilla juntos!" y quiero mantenerte juntos.

2. Si vas a tu jefe, ¿qué tan técnico quieres ser para tratar de explicar tu posición? ¿Cuánta documentación tiene sobre el mal desempeño de sus compañeros de trabajo?

Esas serían las trampas que notaría por lo que preguntaste. Te sugiero que le preguntes sobre el código y veas si tiene algunas justificaciones de por qué es así. Quizás esté corriendo en círculos mientras lo codifica, lo que causa algunos problemas. El círculo es donde codificas algo y luego, a través de una serie de cambios, terminas casi exactamente en el mismo punto en el que comenzaste cuando la lista de cambios de alguien se cancela al final. He estado en esas situaciones en las que está cambiando y deshaciendo cambios tras cambios que se cansan bastante rápido.

¿Cuáles son las consecuencias si no rehace todo su trabajo y simplemente deja que el proyecto falle? Las consecuencias para ti, quiero decir.

Seguramente alguien de su nivel de experiencia y posición no llegó allí por accidente, por lo que su trabajo no es tan malo como lo percibes o toda su carrera está compuesta por personas como tú que lo llevan consigo.

Si está trabajando más de 50 horas a la semana en cualquier proyecto, entonces es algo que está muy mal y se perjudica a sí mismo al no llamar la atención del Primer Ministro o al retirarse. Soy un gran defensor de trabajar de manera MÁS INTELIGENTE, no MÁS DIFÍCIL.

Trabaja con un smart 50 y si el proyecto no funciona, NO ES TU ERROR. Si falla debido a su incompetencia y te culpan, entonces ese no es el entorno para el que te gustaría trabajar de todos modos.

Muchos amigos míos trabajan BIEN durante las 40 semanas típicas en un proyecto mal administrado porque tienen miedo al fracaso cuando no se dan cuenta de cuán poco el fracaso O el éxito afecta directamente a toda su carrera.

Más del 80% de los proyectos fracasan, no hay vergüenza en eso.

Se llama una revisión por pares. Su gerente lo espera de usted, y tiene que ser informado de dónde está gastando el valioso tiempo de su desarrollador. Me sorprende que ya no sepa sobre esto, pero nuevamente, he visto cosas peores.

No le hables en términos del otro chico, háblale en términos del trabajo diario que haces. Si eso significa ignorar su código, que así sea. Vaya armado con enlaces de registro, etc. para dar algún tipo de prueba de su trabajo diario. Su gerente puede querer exactamente esto de usted, por cierto: trae los 20 años de experiencia de usuario y usted obtiene el código robusto. En lugar de hacer wireframes, simplemente escribe un código de nivel de prototipo. Hable con su gerente.

Y espero que no te hayan contratado como su niñera. Buena suerte.

¿Se lanzará el proyecto antes si no tuviera que reescribir / rehacer su trabajo? ¿Ayudará a entrar por debajo del presupuesto? No tiene que criticar, para plantear sus inquietudes en privado. Aquí es donde la mayoría de las personas cometen un error, se quejan sin ofrecer soluciones.

¿Existen recomendaciones específicas que puede ofrecer a su jefe que mejorarán el resultado? ¿Mejor documentación? ¿Pruebas de usuario robustas? Su objetivo es hacer que la empresa, el proyecto, su colega y usted mismo tengan éxito. Pretender que no hay problema garantiza el fracaso en absoluto para tres de los cuatro --- y no eres el afortunado.

Necesitas ir a tu jefe lo antes posible y decirle claramente lo que dijiste aquí.

En primer lugar, este es un dispositivo médico. ¿Podría alguien resultar herido o morir si hay un error? El código de que la vida o la salud de las personas depende de las necesidades debe ser tan sólido como sea humanamente posible, no basura con errores escrita por un optimista para el mejor de los casos.

Bien, poniéndome mi sombrero de ex gerente ... no tienes idea de si tu jefe sabe sobre esto, o cuál será su respuesta si es algo nuevo para él. Pero si él no lo sabe, necesita saberlo, y no debes cuestionarlo ocultando esta información. Si está de acuerdo con que su compañero de trabajo codifique de esta manera, se lo hará saber.

Me encontré con una situación como esta hace muchos años. Un "gurú de las redes" y yo estábamos trabajando en una prueba de concepto como contratistas. De hecho, apenas estaba haciendo nada, y en su mayoría estaba haciendo el tonto. Un día, nuestro jefe nos dijo que teníamos una demo próxima. Pronto, el "gurú de las redes" comenzó a recibir muchas llamadas telefónicas silenciosas, y finalmente me dijo que se iría antes de la demostración para tomar otro concierto de contratación. Tan pronto como pude conseguir a nuestro jefe solo, se lo conté. Dejó al "gurú de las redes" y trajo a alguien que le recomendé, que produjo más código en tres días que el "gurú" en tres meses. La demostración fue un éxito rotundo, pero si me hubiera quedado callado, el proyecto habría fallado por completo.

Sí, díselo a tu jefe. Entonces verás si no eres tú el que está fuera de lugar allí. Es el trabajo del gerente saber cómo está funcionando el equipo y, si el jefe aún no se ha dado cuenta, tal vez simplemente no les importa tanto como a usted la codificación adecuada, como muchos, muchos lugares en los que he estado.

Y entre todos esos diferentes lugares de trabajo, si obtuve una mano llena (es decir, 5) de amigos de todos ellos, eso ya es un gran número. Todos tenían buenos chicos y chicas, pero no perderás una amistad por hacer tu trabajo; si los pierdes, eso es algo bueno. En tu caso, estaría valorando el trabajo más que tú.

De acuerdo, no es un intento de despedirlo. Solo muestra su preocupación por el bienestar del proyecto, por lo que todos ustedes están (o deberían) estar allí.

Después de todo, has intentado hablar con él y, si no haces nada, estás arriesgando tu trabajo allí.