Recuperación de la confianza del programador senior [cerrado]

Mi jefe descubrió que no soy tan inteligente como pensaba.

Un ejemplo de mi experiencia:

Soy un programador junior y trabajo en un equipo de dos, mi jefe (programador senior) y yo.

Me encargaron desarrollar una aplicación web interna para la empresa en la que trabajamos. Escribí el back-end en el front-end (el diseño de la base de datos ya estaba en su lugar y la tecnología del servidor había sido elegida). Periódicamente verificaba mi progreso observando la aplicación web en acción y estaba contento de que llegara. Cuando terminé la aplicación web, estaba satisfecho con lo bien que resultó el producto final.

Hace unos días se interesó en el código, así que le dije qué tecnologías usaba (para el front-end), y aquí es donde se fue al sur. Para el front-end de la aplicación web, utilicé un framework Javascript (Backbone.js). Cuando me preguntaron por qué haría tal cosa. Mi respuesta fue porque sentí que el marco encajaba bastante bien en esta aplicación y me ayudaría a estructurar el código mejor que si lo escribiera desde cero ... "Bueno, eso es desalentador" fue su respuesta.

Entonces, dado este ejemplo, mi pregunta es:

Si usted es un programador senior y ha perdido la confianza en la capacidad de su programador junior, ¿qué le gustaría ver de su junior para recuperar la confianza?

EDITAR : ¡Gracias a todos por las excelentes respuestas y comentarios de apoyo!

Si le gustó el producto que construyó, pero está atrapado en su uso de Backbone, ambos necesitan tener una conversación sobre la pila tecnológica deseada.

Como desarrolladores, debemos usar herramientas que estén fácilmente disponibles y, en consecuencia, mover sin problemas nuestro flujo de trabajo. Si esperaba que construyeras el front-end desde cero, debería haber sido explícito y tener una buena razón.

El hecho de que inicialmente disfrutó del producto es prueba suficiente de que lo hiciste bien y que eres lo suficientemente "inteligente".

tl; dr Lo hiciste bien. Hable con su superior y vea qué espera de usted.

No me parece muy "senior" para hacer un juicio rápido como ese. Siempre tiendo a usar un marco adecuado en lugar del antipatrón "Reinventar la rueda cuadrada". Si fuera realmente mayor, comprendería y conocería el valor de un buen marco. En el mejor de los casos, esperaría que cuestionara la elección de Backbone.js sobre otro framework MVC JavaScript y mucho antes en el proceso. Fracasó en asesorarlo y controlarlo adecuadamente como junior y ayudarlo a lo largo del camino de desarrollo adecuado (en su mente).

Parece que tomó la decisión correcta al desarrollar el proyecto dada la falta de dirección de su parte (supuesto) y está trabajando para ser un desarrollador más competente. Creo que podría ser valioso explicarle su elección de marco, por qué consideró que un marco era apropiado y señalar que el proyecto se realizó y para su satisfacción en parte debido al uso de un marco bien documentado y respaldado. Si no puede progresar, tal vez no tenga valor parecer mejor ante sus ojos. Solo tú puedes responder eso.

La mayoría de las respuestas y comentarios tienen la idea correcta de que usted y la persona mayor necesitarían tener algún tipo de discusión y que puede ser importante para usted intensificar y defender sus decisiones, incluso si su persona mayor no está de acuerdo con sus elecciones .

Para responder a su pregunta sobre lo que me gustaría ver como senior:

Me gustaría ver si mis desarrolladores junior pueden ponerse de pie y defender sus decisiones, aunque sea una ligera decepción. Si estuviera contento con el producto pero no con la implementación, entonces esperaría que los juniors señalaran que debería haber sido más específico en mis especificaciones al darles el producto. Me gustaría que pudieran mantenerse firmes pero también admitir que tal vez no hayan tomado la decisión correcta si ese fuera el caso.

PD: Debo mencionar que soy un senior que adora que se demuestre que estoy equivocado a nivel profesional, ya que eso me da la oportunidad de aprender algo nuevo. Y me gusta ser consciente de cómo otros en mi equipo hacen las cosas para que no haya sorpresas al final de un Sprint / tarea.

En primer lugar, creo que esto debe verse como una oportunidad, no como un fracaso. Obviamente, hay un desajuste en las expectativas y no está claro de dónde proviene, qué debe suceder para que todo vuelva a la normalidad y cosas por el estilo.

En segundo lugar, si toma esto como una falla actual o si no es tan inteligente como cree que establece relaciones de poder que no desea. Entonces, si tomaste decisiones que crees que son defendibles, debes estar dispuesto a defenderlas hasta cierto punto.

Si bien estoy de acuerdo con duggieawesome en que quieres tener una conversación, eso no es suficiente. Tienes que estar preparado para entrar, discutir tus ideas de diseño, explicar por qué hiciste lo que hiciste y defender el razonamiento. También debe aceptar que no hay una sola respuesta correcta y que el programador senior puede tener razones válidas para preferir un diseño diferente y, por lo tanto, desea estar dispuesto a escuchar esas razones sin admitir que sus decisiones fueron mal basadas sobre lo que sabía (a menos que decida que debería haberlo sabido mejor, y eso es otro asunto).

Tenga en cuenta que el diseño suele ser una cuestión de compensaciones. Desea estar dispuesto a discutir cuáles son las compensaciones y ver lo que ambos pueden hacer para asegurarse de que pueden discutir las compensaciones de diseño en el futuro. ¿Quizás ustedes dos esperan que estén más en la misma página que ustedes? ¿Quizás tu jefe es un idiota (puede suceder a veces)? ¿Tal vez realmente tomaste una decisión equivocada dado lo que sabías sobre los requisitos? Sin embargo, entre con una mente abierta y con confianza, y esté dispuesto a hablar realmente sobre esto.

Editar: quiero agregar algo sobre ser inteligente. Las personas más inteligentes que conozco son personas que creen que tienen algo que aprender de todos. Las personas que están cerradas y creen que solo hay una manera correcta no terminan tomando decisiones imaginativamente buenas en áreas como el diseño y no pueden conectar las cosas de la manera en que las personas que están dispuestas a aprender de todos pueden hacerlo. Entrar y estar dispuesto a compartir e incluso intercambiar ideas de un lado a otro es un signo de ser inteligente y seguro. Las diferencias en el diseño no necesariamente se convierten en cuestiones de que uno sea mejor que el otro. Asumiendo diseñadores competentes, diferentes diseños serán optimizados de manera diferente.

Estoy con la opinión general aquí de que no has hecho nada malo. Como desarrollador principal, debería haberse interesado en cómo estaba desarrollando la aplicación, así como los resultados. Entrar después de que se complete un proyecto y decir que no le gusta cómo se hizo no es muy profesional de su parte.

Pero, para responder a su pregunta principal: ¿cómo recupera la opinión que tiene una persona mayor sobre usted después de que se haya perdido? Antes que nada, pregúntales cómo creen que deberías haberlo hecho. Haga preguntas si no entiende y tome notas. Demuestra que quieres aprender.

En segundo lugar, en su próxima tarea, si hay algo que ha quedado fuera de la descripción, presente sus ideas y luego póngalas en práctica por el desarrollador principal. No preguntes cómo hacerlo, porque esto no ayudará a su opinión sobre ti. Pero, si se te ocurren tus propias ideas y tus propias soluciones, pregúntales si estás en el camino correcto, les mostrará que lo estás intentando y que tienes las habilidades para hacer el trabajo. Esto puede ser tan simple como un correo electrónico rápido que dice "Hey, estoy planeando usar x cuando hago y . ¿Alguna idea?"

Tercero, cuando asoman para ver cómo te va, no los dejes irse sin mirar tu código.

Básicamente, abre las líneas de comunicación. Su desarrollador principal no parece ser del tipo que está en usted o en su código, por lo que debe intensificar y ser la persona para comunicarse. Es mejor que todos los involucrados descubran que algo no se pensó exactamente más temprano que tarde.

Una cosa que debe averiguar de inmediato es si está desanimado porque no puede dar una defensa integral de su elección de marco, o si es porque usó un marco.

En el primer caso, es importante que aprenda a evaluar y seleccionar el código de terceros para su inclusión en un proyecto, y que sepa cómo articular esa decisión a sus superiores y estar preparado para defenderla con justificación. Esta es una habilidad difícil de aprender, pero viene con experiencia. También es una buena habilidad aprender porque tan pronto como incluye una biblioteca de terceros en un proyecto, introduce un componente que los otros desarrolladores no pueden comprender completamente, que no tienen control total y pueden contener errores, agujeros de seguridad y otras cosas que deben tener en cuenta.

Si está decepcionado porque no lo escribiste desde cero, entonces ese es un problema completamente diferente. Puede ser que tenga buenas razones para desalentar el uso de marcos (como los que describí anteriormente), o tal vez haya una política de la compañía contra ellos o limite la elección de marcos que puede hacer. De cualquier manera, debería haberte comunicado eso y el hecho de que no lo hizo, indica un fracaso de su parte. Por otro lado, es posible que tenga un caso de prejuicio del marco, porque a pesar de los problemas que los marcos pueden conducir, también tienen grandes beneficios, como estoy seguro de que usted sabe. Es posible que piense que debe hacer todo usted mismo, incluso si eso significa rehacer el trabajo que ya se ha hecho y puesto a disposición del público debido al síndrome del "No inventado aquí".

Que él no te haya explicado por qué está decepcionado de ti por usar un marco es ciertamente un fracaso de su parte para comunicarse de manera efectiva. Te dejó preguntándote qué has hecho mal, cuando la respuesta podría ser "nada". También te hizo cuestionarte, y eso hará que tengas menos ganas de usar tu propia iniciativa en el futuro. Si hay un rasgo que un buen programador no puede permitirse, es la falta de iniciativa. Y aunque estoy seguro de que no fue intencional, su actitud es perjudicial para la moral, ya que de repente se retiró de los elogios por un trabajo bien hecho sobre un pequeño detalle de cómo logró la tarea.

El hecho de que sea el programador principal no lo hace infalible.

Su comentario de seguimiento que decía que el jefe está molesto porque tiene que aprender algo nuevo ...

A menos que haya más que no hayas mencionado, me molestaría.

Aprender nuevas tecnologías es una gran parte de nuestro trabajo y cada equipo debe adoptar el aprendizaje y la superación personal.

PERO, la gerencia tiene otras cosas de qué preocuparse. Tienen plazos que cumplir, tienen presupuestos de capacitación limitados o inexistentes.

Desde el punto de vista de la gestión del hombre, podría ser alguien más trabajando en la fase 2 de su proyecto en lugar de usted. Su jefe podría tener a alguien más en la oreja marcado para hacer ese trabajo, y él sabe que esa persona ahora tiene una curva de aprendizaje para algo nuevo.

Y ahora un PERO sobre el PERO anterior ....... esto es culpa de tu jefe. Si usted es nuevo y junior, debería haberle brindado al menos alguna orientación. En menor medida, también podría haber pedido orientación sobre la tecnología a utilizar.

Si usted es un programador senior y ha perdido la confianza en la capacidad de su programador junior, ¿qué le gustaría ver de su junior para recuperar la confianza?

Dado que usted ha dicho que no quería aprender a usar el marco que utilizó, creo que la pregunta debería ser: " Si usted es un programador sénior y ha perdido la capacidad de aprender de su programador junior, ¿qué debe hacer para solucionarse? "

Como desarrollador profesional no dejas de aprender. Siempre. Si lo haces, te vas a estancar. Y eso podría estar bien en algunas áreas. La banca tiene muchos sistemas heredados en operación que necesitan mantenimiento, por lo que el conocimiento de los sistemas antiguos que se mueven muy lentamente está bien. Un amigo mío estaba editando COBOL para un banco para descubrir que el código fuente que estaba arreglando no había sido tocado en unos 30 años (y el autor original era nuestro profesor de COBOL en la universidad) ... Dicho eso, todavía tiene que aprenda cosas nuevas ya que los sistemas antiguos tienen que integrarse en sistemas nuevos.

De vuelta a su desarrollador senior. Dijiste " estaba molesto por tener que aprender algo nuevo ", y en mi opinión eso suena como una alarma bastante fuerte.

Siempre estoy aprendiendo Aunque realmente me gustaría que mi empleador recogiera mi factura de educación cada año, es raro que gasten algo cercano a lo que siento que realmente necesito, sin embargo, sé que debo seguir siendo empleado, por lo que gasto en algún lugar de la región de £ 2000 GBP (aproximadamente $ 3000 USD) en mi propia educación cada año.

Si su superior no está aprendiendo cosas nuevas, entonces comenzarán a tomar malas decisiones (tal vez ya lo estén) y la calidad del código con el que está tratando disminuirá porque están atrapados en una rutina y no sienten la necesidad de obtener fuera de esa rutina.

Uno de los mejores desarrolladores con los que he trabajado fue un desarrollador junior que sabía todo tipo de cosas que nunca tuve la oportunidad de ver. Él trajo tanto a la mesa que a menudo estaba abrumado. Pero aprecié sus esfuerzos y nunca me "desanimó" por nada de eso. Me complació que se tomara el tiempo para apreciar todas las posibilidades y presentarlas al equipo. Ahora dirige un equipo y sigue contándome sobre los desarrolladores que aportan cosas a la mesa y lo que está aprendiendo de ellos.

Su desarrollador senior necesita aprender cosas. Deben aprender a no usar palabras emotivas (como "desalentador") para ocultar sus propias deficiencias, porque eso afectará la confianza de los demás. Necesitan aprender nuevos marcos (incluso si no pueden aprender todo, aprender qué hace y cómo resuelve un problema, y ​​si lo necesitan en el futuro, pueden invertir el tiempo en aprender más profundamente). Y necesitan aprender que están en un trabajo donde tendrán que seguir aprendiendo todo el tiempo.