¿Es normal cuando el equipo no utiliza el trabajo de un ingeniero de software? Esto sucedió 4 veces en los últimos 2 meses. ¿Cómo puedo mejorar esto?

Recuerdo los primeros meses cuando comencé a programar.

Mi tarea principal era ver la pintura seca.
Bromas aparte, era un principiante. La razón por la que me asignaron a ese proyecto no fue porque me necesitaran. Estoy bastante seguro de que fue todo lo contrario, el equipo tenía poco trabajo para ellos. Tenían mucho tiempo para cuidar a los principiantes.

Independientemente de lo que hiciéramos, un desarrollador senior lo haría al mismo tiempo, más rápido y mejor. Los errores / tareas que obtuvimos fueron principalmente para espectáculos, excepto que no fue así. Solucionamos errores, los desarrolladores senior los revisaban y nos corrigían, a veces usaban parte de nuestra solución, si pasaban por alto algo que nosotros no … eso es todo.

Poco a poco aprendimos qué hacer, qué no hacer, cuándo pedir ayuda y cuándo no (para ser justos, aprenderá esto por el resto de su vida)

No importa la idea aprobada siempre que se resuelva el problema. Asegúrese de saber / descubrir por qué esa idea es mejor. Si crees que no es mejor, expresa tus preocupaciones.
Pero recuerda esto. El código no es tuyo. La solución no es tuya. Pertenece al equipo. La persona que hace la revisión del código decide la dirección porque la compañía cree que puede hacer eso (puede corregirlo, pero podría ser solo una preferencia)

Desde mi experiencia, incluso el mejor código puede estar equivocado. Puede volverse inútil con el tiempo, reemplazado o eliminado. Dependiendo del proyecto, lo que sea que escriba ahora, en 5 años. no habrá rastro de ello.

Recuerdo mi primera tarea real. Todos estaban ocupados, yo no. Tendría que escribir un script para enviar un correo electrónico cada x horas, con archivos que se modificaron en el servidor durante ese tiempo.

No fue complicado, pero no tenía idea de cómo hacerlo.
Ese script se usó durante años y llegó a ser el código más antiguo de ese proyecto, pero no importó que fuera obsoleto algún día.

El mayor sentimiento para mí como programador no es quién tiene el honor de comprometerse, es cuando puedes hacer algo que crees que no puedes hacer, o sabes que puedes, pero no sabes cómo.

Como nota al margen, tuvimos desarrolladores senior que duraron unos meses, pero muy pocos de sus códigos se usaron realmente. Son líderes de equipo en diferentes proyectos ahora. Eran hábiles.

En resumen, no, no importa si el código no se elige. Eso solo significa que tienes un gran equipo. Asegúrate de aprender todo de ellos. Es posible que se trasladen a diferentes proyectos, y la próxima vez usted podría ser el que “enseñe”.

(Supongo que la solución utilizada al final por su equipo es realmente mejor)

Esa sensación de no ser efectivo estará contigo por el resto de tu vida. Nosotros, como humanos, somos escaladores, y siempre hay una montaña más grande para escalar.

Thomas Edison – “ No he fallado. Acabo de encontrar 10,000 formas que no funcionarán “.

Eres nuevo y estás obligado a cometer errores. Incluso cuando les diste una mala opción, tenían algo para comparar. Esto es común, y esta es la única forma en que trabajan las compañías de productos. Hiciste tu trabajo y ellos usaron tus resultados indirectamente.

Tómelo como un desafío, debe aprender cuál es la mejor solución que la suya y tratar de mejorar usted mismo. Llegará un día en que su solución será la mejor y luego brillará.

Existe la posibilidad de que esto sea solo una cadena de mala suerte. Tuve un compañero de equipo que escribió un código en el transcurso de algunas semanas que ahora vamos a eliminar simplemente debido a un cambio en la dirección comercial. Fue muy doloroso Este también fue un gran proyecto, pero a veces hay que estar dispuesto a reconocer la situación y seguir adelante.

Para su caso, pasaría tiempo y pensaría en estos eventos. ¿Hubo un tema común? Cuando solicita comentarios, ¿solicita revisiones de código? ¿Qué sucede con el código que “no se usa”? ¿Está revisando el código o se descarta todo lo que escribió? ¿Su trabajo tiene 1 página (documento de diseño corto) que presenta su estrategia de alto nivel para resolver el problema que se le da? ¿Otros en su equipo experimentan la misma situación? ¿Has hablado con tu gerente sobre esta preocupación?

Las respuestas a estas preguntas pueden darle algunas ideas.

Asegúrese de contar con el consenso del equipo antes de comprometerse con una tarea, idealmente solo trabajo en tareas estimadas, y si hay una tarea de vago, la comparto con el tiempo y escribo mis pensamientos y luego los presento al equipo.